"We've used basic PLCs and I/O for machine control for a long time. Our machines have to do more than before, and we need more connectivity options and a more COTS, standards-based approach to hardware and programming. Some customers are on the PAC bandwagon and think it's the next step for them and us. There are different opinions of what a PAC is. PLC vendors say they make PACs. So do PC-based control suppliers. Does it matter?"
—From August '12 Control Design
Answers
Mashup Control
A programmable automation controller (PAC) can be described as a "mashup" between a PC and a PLC in that it typically offers the benefits of both in a single package. Therefore, it's becoming more common that PLC vendors position their higher-end controllers as PACs — largely because their higher-end products incorporate more connectivity options and broader control capabilities than their PLC lines.
In your situation, the key point is what you state in your question: connectivity options and commercial off-the-shelf (COTS) technology. PACs offer both out of the box. Connectivity options like Ethernet are standards-based and therefore deliver on the COTS promise. For example, standard, readily available components like networking hardware will more easily and cost-effectively interface with a PAC.
In contrast to PC-based control, more often than not, a PAC will have lower running and maintenance costs. One advantage of a PC-based controller is faster computing speed and greater data storage area, but not necessarily faster I/O access. Will your machine accommodate a larger PC-based controller? Is the environment around the machine harsh in any way? PACs are usually smaller and more robust.
Taking all this into account, you must consider your customer requirements, weigh in your machine constraints, and choose the best upgrade. Many options certainly exist, and ideally, you should choose a vendor that provides multiple controller options (both PAC and PC-based for example).
Given the rising use of smartphones and tablets in industrial automation, you should also be looking at a platform that will ease adoption of this technology into your machine. Internet, wireless and cloud-based storage solutions are all growing in use. Select a PAC, PLC or PC that can support these technologies and protocols in a secure manner.
So, does it matter? Yes, I believe so. But, it's your current and future customers that will ultimately help you decide.
Ben Orchard,
systems engineer,
Opto 22, www.opto22.com
The One That Suits Your Needs
PLC is a term generally used to describe a general-purpose controller ideal for controlling standalone, discrete machinery or processes. A PAC refers to a controller that offers multi-discipline control. For example, a PAC might offer the ability to execute complex motion instructions as well as possess integrated safety functionality, while a PLC typically would offer only logic control.
Some PC-based control suppliers might offer PACs, but not all PC-based controllers are PACs. The terminology is often interchanged, even among the most savvy machine builders.
Here are some questions to help guide you:
1. Does your application require multi-discipline control (motion, safety, drive, process, etc.)?
2. Do you have panel size constraints that should be considered?
3. What is the expected lifecycle of the machine?
4. Is rugged packaging required?
5. What networks will you be using for your machine design?
Overall, the terminology is less important than selecting the controller and vendor partner that best meet your specific needs.
Dexter Leong,
product manager, CompactLogix,
Rockwell Automation, www.rockwellautomation.com
A Controller by Any Other Name…
I think the concept of a PAC, while technically defined, is more of an all around automation "solution" piece of hardware, rather than the simple I/O controller we're used to in PLCs. It used to be that the control system ended with the PLC, and users interacted with an HMI to report this to the office, where the numbers were punched in again. Then we added SCADA, and had to move information out of the PLC and into a more PC-based environment.
It's inevitable that the next step of control systems would be to integrate a more tight-knit linkage with the systems where the information needs to flow, and often that information needs to flow to an IT-controlled system. So really, I think PLCs are becoming the less-expensive alternative to a PAC and becoming PACs in all but name, and PC-based control systems are "hiding" their PC background and moving toward a form factor and user interface much more akin to the traditional interfaces we're used to in the controls industry. Really, I don't think it matters.
What does matter is that you find the proper tool for the job, and more and more we're seeing connectivity options increase across the board. Standards-based programming gives us the ability to teach the next generation of controls engineers how to program independent of manufacturer, and often to pick and choose what language is the best for the particular programming option. It's an exciting time to be in this industry!
Dan Fenton,
control and software product marketing,
Phoenix Contact, www.phoenixcontact.com
Often Not Required
The "Real Answer" is that is doesn't really matter. PAC is simply a term used by some suppliers to describe what others would call PLCs and PC-based controllers. In general, it refers to hardware that goes above the simple ladder logic found in classic/basic PLCs, and that can incorporate higher-level control such as PID and sequence control.
Nowadays, the majority of PLCs offer this higher level of functionality, with standard programming languages, connectivity for multiple bus systems, and functional expansion through add-on modules. PC-based systems offer similar functionality, with a PLC kernel and additional interfaces to allow integration of standard PC technology and peripherals.
PACs often offer a higher level of performance, integration of higher-level PC languages and visualization possibilities combined on one system. This convergence of technologies provides benefits of consolidation of tasks into a single system, but brings with it an inherent increase in complexity.
In the end, today's PC-based and PLC offerings can both handle most applications. The one that is right for you depends on your specific application, functional requirements and knowledge. Both types of systems come off-the-shelf with industry-standard communication and engineering, and offer enough flexibility that proprietary solutions are far more costly and often not required.
Sydney McLaurin Jr.,
PC-based automation marketing manager,
Siemens Industry, www.usa.siemens.com
Some Things Matter, Some Don't
There certainly are varying definitions of what a PAC exactly is vs. the traditional PLC. As a machine builder, the primary concern shouldn't be in the terminology. Instead, consider other aspects when faced with having to add the features listed in the question. What level of functionality and performance is required for controlling a particular application? Is there an automation platform available that can offer right-sized and cost-efficient hardware for not just a single machine, but an entire machine portfolio? Can the automation platform easily be customized with off-the-shelf products to adapt to changing needs and can it do that while reusing any existing application software? Is the hardware and software built on a modern architecture that ensures both innovation and long-term availability?
From my perspective, the main difference between a PAC and PLC is that a PAC provides better control of the timing of the application program(s) that run on the controller. In a PLC, the program typically runs in a continuous mode, meaning that as soon as one scan finishes, the next one starts. The advantage is that small programs run fast even on low-end hardware, but as the program grows, so does the program runtime, thus slowing down reaction times. Another disadvantage is that as different program conditions execute more or less code per scan, the program execution time varies, leading to inaccuracies that will have a negative impact on the repeatability from one machine or product cycle to the next.
On a PAC, the program will run in a scheduled cyclic mode. Here, an underlying real-time operating system will schedule program(s) in cyclic tasks with different priorities and cycle times independent of the program execution time. This allows the application to be separated into programs running in a fast cycle time for time-critical tasks (e.g. digital I/O processing) and slower cycle times for less time-critical tasks (e.g. PID temperature control and HMI logic) on the machine. What might look more complex at first really offers much greater flexibility to any machine builder in designing the application software and achieving better production accuracy and repeatability due to a constant timing.
Another common difference between a PAC and a PLC is the ability to incorporate additional functionality like motion and robotic control, remote or onboard visualization, file handling, web server, etc., on the same piece of hardware, allowing consolidation of multiple controllers into a single one and offering value-adds in terms of diagnostics and data collection capabilities.
This is the area where the lines from PLC to PAC and PC begin to blur depending on what functionality the underlying hardware and operating system architecture of the controller allows. Some manufacturers are using microcontroller- or RISC-based architectures, which are in essence a "PLC on steroids" — faster and with better timing but not too much more functionality common in a PC-based architecture.
Some PC manufacturers come from the other end — taking an industrialized PC with a real-time operating system and maybe a second OS like Windows and calling it a PAC or "soft PLC." Such systems offer great performance and additional functionality, but can't necessarily be scaled down cost-efficiently for lower-end applications because of the PC hardware overhead. They might also lack features common in a PLC like non-volatile memory to retain tag information through a power cycle.
Robert Muehlfellner,
director of automation,
B&R Industrial Automation, www.br-automation.com
PAC or Enhanced PLC?
It doesn't really matter what you call the controller; the real issue is the functionality you need and how much are you willing to pay for it. PLCs have been enhanced with extra hardware and software over the years to handle more than their original function of sequential logic. PACs were introduced as some companies saw a more cost-effective way to handle motion control, visualization, more advanced calculations, and connectivity to supervisory and ERP/MES systems.
These alternative suppliers to traditional PLC vendors realized that they could provide all of these extra functions without the extra cost of additional hardware and software by using a powerful industrial PC processor as the core of their controller. These powerful devices were called PACs at first to differentiate them from "enhanced" PLCs.
Unfortunately, some PLC vendors answered this development by calling their enhanced PLCs "PACs" as well, leading to confusion with the term. While PC-based solutions use standard, off-the-shelf technologies and manage more functions in software, the PLC-based PACs tend to rely more on proprietary add-on hardware.
Again, you must look at the cost and functionality you need, and choose the best technology for your applications. In general, you will get more advanced functionality, higher performance and a lower cost if your controller uses a PC-based design, as it can handle all of the tasks within one CPU and with one software package. On this note, the advent of multicore processor technology in PC-based control technologies has given a considerable lead to the controllers that incorporate them over their traditional PLC-based peers. Also consider that less hardware and software is normally a good engineering principle for improved lifecycle management.
The most important consideration is how it can deliver enhanced functionality while also having the best price-to-performance ratio.
Graham Harris,
president,
Beckhoff Automation, www.beckhoffautomation.com
