Programmable Logic Controller (PLC) or Process Automation Controller (PAC): What’s the difference? Should we even care? That’s what I was wondering when I recently ran across this term.
In reading a few definitions I see there are some differences appearing, but generally the following excerpt seems to capture what a PAC is.
A PAC is often used in industrial applications for process control, data acquisition, remote equipment monitoring, machine vision, and motion control. A PAC functions and communicates over popular network interface protocols like TCP/IP, OLE for process control (OPC) and SMTP. PACs are able to transfer data from the machines they control to other machines and components in a networked control system or to application software and databases. A PAC at the core of an automation system can integrate multiple field bus networks like RS-485, RS-232, RS-422, CAN, Ethernet, Ethernet/IP, and others.
Does this sound like a description of a modern PLC to anyone but me? PLC’s have migrated into becoming automation controllers without many of us realizing it. Integration of motion, communications, the use of open standards, process control and discrete logic capabilities and good data handling abilities is what controls engineers have always wanted. In the good ole days we had to spend considerable time getting things to work together. Now the PLC manufactures/suppliers are also the automation manufacturers/suppliers. They have moved to increasingly integrate their own controls and even allow 3rd party controls to be integrated in to their PLC/PAC products. Some have even integrated an HMI into their PLC programming environment.
So the big question is, “do we call it a PAC or continue to call it a PLC”? I’d say it depends on who you are talking to? For the sake of conversation with most clients, it is easier to continue to refer to the Automation Controller as the PLC. If you do, everyone will generally understand what you are talking about. Additionally everyone is comfortable with PLC’s. Calling it a PAC will often require additional explanation and might make clients a bit nervous if they expected a PLC. On the other hand if the client prefers calling it something other then the PLC who are we not to adopt the clients preference?
It looks like the PLC vss PAC naming decision is like the VFD vss VSD decision. Most controls engineers know that most VFD’s are usually not run as true VFD’s (Variable Frequency Drives) as the drive control algorithms have become more sophisticated and more varied, and we really should just refer to them as VSD’s (Variable Speed Drives). However, since the first VSD’s for standard AC (induction) motors were all VFD’s this naming convention has stuck, so we continue to call them VFD’s.
What are user preferences for naming the controllers and drives?
Harold On Controls 
Rockwell automation’s ControLogix is a PAC but Rockwell never seemed to push the issue until National Instruments started making a big deal about the Compact RIO being a PAC. I agree with what you are saying and believe 99% of the time it doesen’t make any difference what you call it. I helped launch the first ControLogix platform at GM and remember the only real difference being the tag conventions for I/O and the fact the I/O is updated continually not just at the end of a scan. The fact that I/O is always being updated during a scan can sometimes cause unexpected issues but can be easily delt with through programming. I don’t get hung up on the PLC vs PAC unless someone is making a big deal about which is better and I like VFD.
By: Chris Alexander on February 2, 2010
at 11:16 am
Nice try Harold! I feel that in your well written article, you tried to shift the discussion on a lexical plan. However I still believe that modern PLC have PAC same capabilities, but not the same flexibility and compactness… How many communications modules, accessories, “special” cables, and software licenses would you need for a PLC to achieve the same functional capabilities of a PAC?
By: Michele Brami on February 3, 2010
at 4:48 am
For the AB/Rockwell ControlLogix PLC there is no additional software needed to program motion or straight logic or process type controls for example.
What are examples of PAC controllers that you find worth considering?
By: Harold Ennulat on February 3, 2010
at 11:29 am
Good point Harold. Even the AB MicroLogix 1400 has 3 Comm ports and motion module as a standard module offering. No Additional software needed. MicroLogix is the lower end PLC and has great functionality for smaller projects.
I worked for Rockwell for 4 years and believe they have some great products but I have also used Mitsubishi, Omron, TI, Modican, ect. and all the PLC’s are fairly easy to program and most have a product that does what a PAC does. The differences are down on the processor level and don’t tend to make a big difference in most cases.
I have run into cases where people just want to use the latest and greatest and spend $10K -$15K on a NI PAC system when an AB MicroLogix does the same thing for $2.5K and the program is delivered in half the time. On the other hand I have seen applications in a Lab or Quality environment when a controlled process needs to collect a lot of data in which the NI PAC was clearly the right choice. I have used the NI platform and the things you can do with data inside the PAC are great and the speed at which data is collected will always beat a PLC.
The reality of the situation is that most industrial applications do not require all the bells and whistles that come with a PAC and the PLC does not meet the needs of most laboratory environments. If controls engineers just do what is right and pick the right controller for the job and get past what they are comfortable with the controls world would be a better place. Remember the salespeople are working on commission at all times.
By: Chris Alexander on February 10, 2010
at 7:09 am
As I’ve not an automation expert, I would not normally quibble with such semantics but, according to the ARC Advisory Group’s original formulation, PACs’ by DEFINITION consist of the following requirements:
– Multi-domain functionality in terms of logic, motion, drives, process, and so on
– Single multidiscpline development platform
– Software tools for designing applications across several machines or process units
– De-facto standards for network interfaces, languages, etc
– Open, modular architectures.
This definitional emphasis on my part stems from my wanting to come to terms with PACs lifecycle impact on integrated standardized (ie proprietary, single-box) microprocessor-based motor controllers.
Microprocessor have historically had, and will inevitably continue to have, a high impact on motor controllers:
– In large surface fixed-speed motor applications Following the wildly successful introduction of the Multilin 269 controller by Markham Electric’s founder in the late 1970s and acquisition under Jack Welch’s watch, the GE Multilin division evolved into a broad line of microprocessor-based proprietary controller products including in terms of the Multilin 269/369/469 motor controller family in particular and, eventually, the phasing conversion of all GE electro-mechanical protection relays generally.
– In submersible motor (ESP) applications Starting in the late 1980s, small entrepreneurial manufacturers have dominated the first generation of microprocessor-based ESP motor controllers, which were eventually absorbing by large oilfield service firms either partly or fully by manufacturing acquisition, or, development of second generation of proprietary motor controller, the latter controller being ‘universal’, ie in PAC parlance, more multi-domain/functional in it coverage of the oilwell data universe including in terms of fixed-variable-speed function enhancements, system/hardware redundancy elimination, inclusion of reservoir & subsea acquisition & monitoring, and so on.
– In AC variable speed drive (VSD) applications VSDs have been generalized characterized in recent years with marked improvements of cost, size, application performance, simplicity, smart power including in terms of specialized embedded motor controllers, and so on. Improvements to MV VSDs have been so much as to significantly lower the breakeven point between LV and MV drives. Similar improvements in automation, including in terms of PLCs and the advent of PACs, are tending to make it increasely attractive for VSD manufacturers and their systems integrators to develop their own VSD-centric motor controllers around PLCs/PACs and HMIs.
Questions: In short to medium term future:
– in case of VSDs, to what extent will motor controllers coalesce around their own small/dedicated VSD-centric PLCs/PACs and HMIs?
– in case of VSD with small dedicated PACs, to what extent will redundant/hierarchical PACs be used for automation?
– in case of Multilin 269/369/469 family, to what extent will this family continue to dominate as standardized proprietary single-box controller devices?
By: Claude Lambert on February 25, 2010
at 11:05 pm
Here is nice update to original question posed:
http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/ContentDisplay.cfm&ContentID=82268
By: Claude Lambert on July 21, 2010
at 2:14 pm
Nice Find. In fact I liked it so much that I turned it into a new blog entry at https://hennulat.wordpress.com/2010/07/21/isa-web-exclusive-unraveling-pac . Thanks.
By: Harold Ennulat on July 21, 2010
at 4:58 pm
Claude, I’m curious where you got that “definition” for a PAC? The link you sent later I thought said that there was no accepted definition. I’m just noticing now that the definition in your comment seems to come from a particular vendor/supplier point of view. That was the point of the “unraveling PAC” article: that while there are similarities in peoples definition there isn’t any agreement on a single definition… at least not as of the middle of Jully….
By: Harold Ennulat on September 20, 2010
at 8:29 am
Harold,
PAC definition is said to have been coined by Craig Resnick, Director of Research with ARC Group, ARC being an automation researching and consulting organization . Refer below (for example) to the two links and excerpt from the first link. You will have to sign in to get access to ARC Group. And, yes, I find it especially interesting that ISA’s “unraveling PAC” article appears to studiously ignore mention of this definition and its origin.
My take of this is that ARC’s definition is an ideal Resnick sought initially but in absence of a standard various manufacturers with of course tend to wander from this ideal.
Claude
A Comparison of PACs to PLCs – Developer Zone – National Instruments – http://zone.ni.com/devzone/cda/tut/p/id/2960
Excerpt:
In their “Programmable Logic Controllers Worldwide Outlook” study, ARC identified five main PAC characteristics:
• Multi-domain functionality, at least two of logic, motion, PID control, drives, and process on a single platform
• Single multi-discipline development platform incorporating common tagging and a single database for access to all parameters and functions
• Software tools that allow the design by process flow across several machines or process units, together with IEC 61131-3, user guidance, and data management
• Open, modular architectures that mirror industry applications from machine layouts in factories to unit operations in process plants
• Employment of de facto standards for network interfaces, languages, etc., such as TCP/IP, OPC and XML, and SQL queries
The Evolution to the Programmable Automation Controller by ARC’s Craig Resnick
http–www.arcweb.com-KeyConcepts1-The%20Evolution%20to%20Programmable%20Automation%20Controllers.pdf
By: Claude Lambert on September 20, 2010
at 10:41 am
Thanks Claude for the additional insight.
By: Harold Ennulat on September 20, 2010
at 6:44 pm
[…] PLC or PAC? VFD or VSD? February 2010 10 comments 4 […]
By: 2010 in review « Harold On Controls on January 10, 2011
at 4:24 am
What about Industrial PC’s that are Windows based such as “Beckhoff”?
By: andreik on July 21, 2011
at 1:15 am
Industrial PC’s as a PAC or PLC?
Is that what you meant?
If so I haven’t been a big fan of PC’s for plant control (industrial or otherwise). They are OK for Lab or applications where the operations can be interrupted to reboot or to reload the application if/as needed AND you have the technical expertise around still to do all of this….
You’ve given me another idea for a new blog post, because there is a lot more that can be said about the subject of using PC’s in automation projects. Thanks Andreik.
By: Harold Ennulat on October 22, 2011
at 1:33 pm
A couple primary inaccuracies to point out so every one is kept straight. 1 in in your blog post, 1 in content distribution site automation.com’s PDF you referenced. In you blog you started off defining PAC: as “Process Automation Controller”. That is incorrect as it is “Programmable Automation Controller”. In the content distribution site automation.com’s PDF, they have side by side comparison chart, but they got PLC &PAC in column header switched around. Below features for PLC, they list PAC features, below PAC column, the list PLC features. distributing the above two mistakes adds to our industry personnel being confused. so I just wanted to clarify those two primary points. A new and more accurate comparison chart can be found at http://bin95.com/What-is-a-PLC-PAC-Difference.htm
By: don fitchett - Industrial Training on March 1, 2013
at 6:17 am
It seemed to me that when I did the research for this article that there wasn’t universal agreement on what a PAC is or is suppose to be. Thanks for your comments.
By: Harold Ennulat on March 2, 2013
at 10:47 pm
See @Control_Design 2015 Readers’ Choice Awards: PAC
1. Rockwell 2. Siemens 3. Schneider Electric 4. GE Intelligent http://www.controldesign.com/articles/2015/2015-readers-choice-awards/ These are the major players who all offer PACs (in addition to legacy PLCs.)
By: Business Industrial Network on August 31, 2015
at 3:48 pm
A couple primary inaccuracies to point out so every one is kept straight. 1 in in your blog post, 1 in content distribution site automation.com’s PDF you referenced. In you blog you started off defining PAC: as “Process Automation Controller”. That is incorrect as it is “Programmable Automation Controller”. In the content distribution site automation.com’s PDF, they have side by side comparison chart, but they got PLC &PAC in column header switched around. Below features for PLC, they list PAC features, below PAC column, the list PLC features. distributing the above two mistakes adds to our industry personnel being confused. so I just wanted to clarify those two primary points. A new and more accurate comparison chart can be found at http://bin95.com/What-is-a-PLC-PAC-Difference.htm
By: don fitchett - Industrial Training on March 1, 2013
at 6:17 am