Programmable automation controllers (PACs) and industrial PCs

A programmable automation controller (PAC) is an industrial controller that combines the functionality of a PLC with the processing capability of a PC. The term programmable automation controller is generally accepted as having been coined by the ARC Advisory Group, which specified five characteristics that define a PAC:

• Multi-domain functionality

• A single, multi-discipline development platform

• Flexible software tools that maximize process flow across machines or processes

• An open, modular architecture

• Compatibility with enterprise networks

But with no industry-standard definition of a PAC, the distinction between PACs and PLCs is blurry. Higher-end PLCs now incorporate some of the characteristics described above and are encroaching on what was once considered PAC territory. In fact, many PLCs now include standard programming languages, the ability to expand functionality through add-on modules, and connectivity to various bus systems.

PACs still differentiate themselves from PLCs by employing a more open architecture and modular design. They’re also more capable than PLCs at monitoring and controlling a large number of I/O, such as in a large processing plant or a complex automation system. They do this because data can be exchanged between devices and applications in different domains, such as motion and process control.

In addition, a programmable automation controller can send and receive data to and from other PACs, creating a distributed control system of PACs.

Programmable automation controllers (PACs) excel in commanding complex automation setups that involve PC-based and HMI functions as well as process control (largely because of the way they handle I/O). PACs are also increasingly common for motion applications for machining or handling discrete product thanks to the flexibility and interoperability they offer machine designs.

Today’s PACs evolved as an option for complex control when microprocessors with significantly more performance became affordable and commonly available. PACs differ from the still-dominant form of control for motion — the programmable logic controller (PLC) — in that all PACs can perform as PLCs but not vice versa. That’s because PACs serve multiple channels of communication; high-data traffic; and coordination with intelligent subsystems. Most performance PLCs can host intelligent processors in their backplanes — such as Ethernet modules with multiple ports for expanded data and communications, for example. But such setups can be expensive where vendors’ proprietary backplanes and operating systems are costly.

Consider how PACs emulate the behavior of electric-relay controls. Relay logic executes sequentially with repeatability and reliability — on hardware rugged enough to survive hard industrial settings. All logic rungs are defined by inputs and outputs that are logically connected to trigger actions after satisfying precise circuit-logic conditions. This means one logic rung can’t execute without preceding conditions met first. Extra left-hand power rails for loops and jumps extend relay-system capabilities to build complex logic ... but larger and more complex permutations of these setups can be costly to build and maintain.

In fact, PLCs themselves replaced relay-based controls and were the first standard as electricity became the dominant power source for manufacturing. As control requirements became increasingly complex, hard-wired relay control became impractical because manufacturing needed more reliable and reconfigurable (programmable) systems. Given the primitive hardware and rigid task execution, early PLCs were difficult to network. Today’s PLCs are quite easy to implement. The first PLC in the late 1960s used available electronics that duplicated the behavior of relays — plus were programmable instead of hardwired. This necessitated proof of repeatability and reliability on the plant floor. So custom memory boards, logic-controller boards, backplane interfaces to I/O modules, and heavy-duty circuitry helped these PLCs to run in industrial environments. It was a new concept to let users write application code using the symbols and logic of relays.

Today’s PLCs are still more appropriate than PACs in standalone applications such as machine axes that run preset sequences. The rule of thumb is that anywhere PAC functions would otherwise go unused, it still makes sense to use the a more economical PLC. Pressure from plant personnel and the enduring value of ladder logic also make PLCs the first choice in many applications.

WHERE PLC SETUPS YIELD TO PACS — AND THE DRIVE OF DCS, RTU, AND PC TASKS

As various industries came to accept PLCs, they came to be used in myriad applications. Increased PLC use has also followed the continuous improvements in their speed, ability to run complex math functions, and communication networks.

But once PLC behavior was proven reliable on a computer, the PAC was born. The aerospace and medical industries are two driving industries. The FAA and FDA mandate that day, date, and timetagged data about manufacturing processes are stored for extended periods of time — particularly well run on PACs. Even manufacturers of simple consumer products are finding such information necessary for defending designs in product-liability lawsuits. What’s more, it’s not just product-data logging that leverages the data-tracking functions of PACs; running predictive maintenance and operations monitoring uses data from controls, too. That necessitates more data and complex network interactions — which means PACs will only become increasingly common.

Just as PLCs, the controls known as distributed control systems (DCSs), PCs, and remote terminal units (RTUs) include hardware and programming to satisfy specific applications. PAC hardware can run functions as software to replicate legacy forms of these and other pieces of motion-system hardware. Here’s the catch: Early-generation versions of all these controls were engineered with features to serve specific markets. So for today’s engineers working in siloed industries served by these legacy controls, the way in which PACs replicate several control schemes boosts convenience and familiarity duringimplementation.

Note that computer processors’ increasing capabilities and declining cost have blurred distinctions between various control types. Case in point: The PAC itself is the extension of the PLC to incorporate greater data-processing and communications capabilities incomprehensible when the PLC was invented.

Originally, DCSs were a collection of RTUs operating on normal phoneline networks, and their communications were simple alarm states from remote equipment. RTUs were small standalone controllers to execute modest logic tasks — usually off simple information such as elapsed runtime or total units of counted, for example. Early DCSs didn’t transmit data, but one could rent a line from the phone company and create an alarm to indicate that a process value had been exceeded or the RTU needed reading, for example.

Industrial PCs have advanced with processor capabilities following Moore’s law. Early industrial PCs were merely programming terminals and storage devices, because their operating systems weren’t robust enough for industrial controls. Now there’s no such limitation, because of vastly improved hardware and widely available real-time operating systems such as Linux for IPCs.

Some PACs have multi-processor architecture to support multiple programming environments — and run multiple DCS, RTU, PLC and PC functions. PACs also have high-bandwidth internal architectures that allow multiple processors and multiple tasks to simultaneously execute ... so designers can create controls to satisfy complex and concurrent requirements.

PACs AND CONNECTIVITY

PACs are generally sold by companies with mature I/O offerings, but the fact that PACs support Ethernet means there’s more I/O independence than ever for system designers. Design engineers can choose the I/O product that best suits a given application — or one that’s compatible with an existing installed base of products.

Integration of a PAC into data-reporting schemes is usually easy thanks to builtin communications options in the basic hardware. There’s also support for modems and wireless-network layers — for built-in remote communications to data systems outside the plant environment. There are also protocols to facilitate interfaces with data systems such as Oracle and SAP — so tools abound for using PACs in datacentric applications.

Video interfaces are more common (and growing) in discrete part manufacturing. More PACs than ever work with smart videos to verify dimensional accuracy — which in turn boosts product quality. Common video subsystems can interface directly to PACs. In the past, videoto-PLC interfaces required a great deal of extra programming.

Motion control integration into discrete part-manufacturing operations often works well on PLCs if the motion consists mostly of independent single axes. Here, a smart-axis controller built into the motor drive electronics can operate with digital handshakes to the PLC. Runs, stop inputs, and busy signals from the motor control can often suffice.

However, applications that need more coordination or speedier movements don’t run well off PLCs. That’s because PLCs limit system performance — and that can jeopardize whole automation projects.

In contrast, PACs use of high-density memory and solid-state disks, so can process much more data on the fly. Should there be a machine problem, PACS can access extensive documentation or serve it under software control to facilitate repairs. That improves machine availability and productivity. In fact, these features can sometimes integrate into HMIs when there is sufficient memory. However, PACs integrate such function directly into application programming.