PLC vs. PAC vs. IPCs

Know the features, limits, and compatibilities to select the right controller: programmable logic controller (PLC), programmable automation controller (PAC), or industrial PC (IPC). Choosing the correct control platform from the beginning will increase the odds that the project will be a success. A system integrator can help with controller selection.

By Ryan Williams November 16, 2015

Control systems today are more powerful, more flexible, easier to configure and program, and easier to communicate with. The vast number of companies creating control systems and the multiple lines within each company can cause some paralysis when trying to determine the right make and model of controller for a project. With a little understanding of the different features, limitations, and compatibilities of different offerings, an engineer can make an educated decision when choosing among programmable logic controllers (PLCs), programmable automation controllers (PACs), or industrial PCs (IPCs). 

Controllers replaced relays

Up until the late 1960s control systems consisted of relays controlling discrete functions and independent loop controllers controlling analog functions. This posed many challenges including the consumption of very large spaces for the relays, expensive and time consuming changes, and often monumental troubleshooting efforts.

In the early 1970s the PLC was created and began to be widely used in industrial applications replacing relay systems. The first PLCs were large (though much smaller than the walls of relays), and programming was done with dedicated terminals and a very limited instruction set. In the late 1970s distributed control systems (DCSs) began replacing individual loop controllers and centralizing the process analog control environment. DCSs typically consist of multiple input/output (IO) racks located in close proximity to the end control devices and a PC-based visualization and engineering station. The graphics or engineering screens are an integral part of the DCS and used to interact with the process or tune loops. In the early 1980s PLC systems began to take the path of DCS systems and contained distributed components and racks.

PLCs have seen many advances including increased processing power, increased memory, increased bit handling, and decreased size among others. These advances have also pioneered several classifications of automation systems beyond the original PLC concept. Two of these classifications include process automation controllers (PACs) and industrial PCs (IPCs). While PLCs retain the same basic concept that they did in the early 1970s, PACs and IPCs add some new capabilities and functionality that sets them apart from the basic PLC concept.

PLCs

PLCs remain the basic building block for many smaller automation projects. Today’s PLCs are very powerful and capable controllers. Common uses include original equipment manufacturer (OEM) machines, such as packers, fillers, palletizers, and small process skids. PLCs are typically paired with a machine-level, human-machine interface (HMI) package for visualization and alarming. PLCs are capable of handling very high-speed I/O, sequencing, proportional-integral-derivative (PID) control, digital and analog I/O, and instruction sets well beyond the original PLCs of the 1970s and 1980s. Additionally, depending on the make and model of PLC, there are often a whole host of other specialty modules available for high-speed counting, network interface, motion control, and other options.

Nearly all PLCs have some sort of standard built-in field-, device-, or Ethernet-level communications. These include networks such as EtherNet/IP, Profibus, Profinet, Foundation Fieldbus, or Modbus TCP. These networks allow for peer-to-peer (PLC-to-PLC) communications, distributed I/O capabilities, and HMI/SCADA communications. While they are very powerful compared to PLC systems of many years ago, today’s PLCs still have limitations. To keep pricing down in this competitive arena there is a limit to the amount of I/O that they can handle as well as the amount of logic that can be installed.

PACs

Larger projects requiring several distributed racks or very large applications typically require more processor power and memory than a basic PLC package. PACs contain all capabilities of the PLC systems listed above plus additional features.

PACs are designed for much larger distributed control such as applications like large packaging lines, discrete manufacturing control systems, and process control of larger skids or plant processes. The instruction sets available are more advanced and purpose-built, such as process control, sequencing, batching, and device control. Some manufacturers go so far as to build and publish industry-specific instruction sets for oil and gas, nuclear, brewing, and other specialty areas. These special instruction sets are typically very powerful and processor-intensive, which require the increased capabilities of the PAC field to execute correctly. PACs often are used with enterprise-level supervisory control and data acquisition (SCADA) systems for plantwide control and data collection.

The advancement of PAC instruction sets and corresponding HMI libraries has blurred the lines between PACs and DCSs. Much of the functionality, power, and integration of a DCS are now being provided by the PAC manufacturers. They are capable of advanced control, historically reserved for large DCS systems, such as model-predictive control (MPC) and fuzzy logic, which are used in otherwise unstable or complicated closed-loop control where PID is inadequate.

IPCs

Industrial PCs got their start in the 1990s with automation companies designing software emulating a PLC environment that runs on standard PCs. These first attempts at using PCs for automation were often unreliable as they were subject to the stability issues of the host operating system (OS) and failure rates of nonindustrialized computers.

Since then, there have been many advances in the IPC field including the use of hardened industrial computers, more stable operating systems, and even some manufacturers have created their own purpose-built IPC with real-time kernel for the automation environment. This real-time kernel allows the automation to be separated from the operating system environment and take priority over the OS for priorities, such as I/O interfacing.

Because IPCs run on PC platforms, they contain more modern processors and more memory than standard PLCs. One advantage of IPCs is that it is often possible to run the HMI application on the same machine as the automation program and decrease cost. Some uses of IPCs include OEM machines and skids and other small projects where space is limited. 

Select the right control system

There is no clear cut fast rule about when to use a PAC, PLC, or IPC. Many factors come into play, such as budget, size, support, complexity, and future expansion. Careful attention needs to be paid to processes and systems requiring safety integrity level (SIL) certification for safety and mean time between failure (MTBF) times.

Often the customer (internal or external) determines, at least, the brand(s) of control system that is being provided. This is typically due to existing programming licenses owned, maintenance and engineering training and familiarity, and regional contractor support for the system.

When a technology selection is unclear it can help to create a selection matrix with weighted criteria and then grade each technology. Weigh more important criteria or needs higher than wants or less important criteria. An example of this is shown in Figure 5, the technology selection matrix example.

Creating an objective table helps remove some subjectivity from the decision. Such a table is useful when customers do not have a standard in place or when the standard leaves room for a system integrator to recommend a solution type and brand.

A solution also could be a hybrid mix of PLCs, PACs, and IPCs. Today’s industrial networks allow for a tightly integrated plant floor even with multiple controllers spread out across multiple brand lines.

An experienced systems integrator should be able to assist in making the correct decision for a project based on the needs and wants of the customer. Choosing the correct control platform from the beginning will increase the odds that the project will be a success.

– Ryan Williams is a project manager at Stone Technologies, a control system integrator and prior Control Engineering System Integrator of the Year in 2010. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, mhoske@cfemedia.com

Key concepts

  • PLCs, PACs, and IPCs serve various control applications.
  • Making a matrix of weighted criteria can help in deciding which is best.
  • A combination of controllers and vendors may be used.

Consider this

Configuration and startup are very painful times to realize the chosen control platform isn’t suited for the application.

ONLINE extra

Stone Technologies was a Control Engineering System Integrator of the Year in 2010. 

References

E. Csanyi, "When we started to use PLCs after all?" (December 21, 2011), retrieved from Electrical Engineering Portal.

D. Frede, "How Industrial Data Was Born (Part I)," (January 3, 2013), retrieved from GE Automation.

Microbox PC Simatic IPC427D, (n.d.), retrieved from Siemens. 

Segovia, V. R., and A. Theorin History of Control History of PLC and DCS. June 15, 2012.

Author Bio

Ryan Williams is a project manager at Stone Technologies with a long background in multidiscipline engineering and cross-functional team leadership. He has a successful background in architecting and implementing challenging engineering projects in industrial and commercial environments. Expertise includes:

  • Project/engineering management
  • R&D engineering and leadership
  • Project and services sales
  • Plant floor automation, process safety systems, data acquisition, reporting systems including overall equipment effectiveness (OEE), manufacturing execution systems (MES), manufacturing operation management (MOM), and batching solutions
  • Multidiscipline (mechanical, electrical, IT, management) engineering
  • All phases of project lifecycle including quoting, budgeting, scheduling, and managing/execution
  • Silicon/semiconductor, automotive, food and beverage, chemical, hydroelectric power generation, beer and wine, and consumer goods industries.

He has formal training in Rockwell Automation PLC5, SLC, ControlLogix; Siemens S7, PCS7, Siemens Braumat; and Emerson Process Management DeltaV, DeltaV SIS; as well as an ISA S84 SIS Fundamentals Specialist and ISA S84 SIL Selection Specialist.

Link to related controller articles below.

Stone Technologies is a CSIA member as of 11/30/2015


Author Bio: Ryan Williams is the national product manager for Solutions and Service at Endress+Hauser USA. He graduated from Purdue University in 2005 with a degree in electrical and computer engineering technology. He came to Endress+Hauser with more than 14 years of experience at Rockwell Automation and has been with the company since 2018.