If the application is relegated to one machine and there is limited I/O and limited footprint, then I would choose a PLC. If you are working with a large machine and you need a group of controllers and a high-level HMI in more than one location around the machine and it must feed back to a corporate higher-level system, then a PAC is a good idea. One of the differences between the PLC and the PAC is the PAC may have more memory or dual cards/cores, which applies for multiple applications, or increased architecture complexity.
PACs are more integral in system safety, as well. Some control architectures set up a card in the rack to be dedicated to safety. Others modularize the software, so the safety is separated out modularly via memory on the controller. Simple PLCs would not have this capacity. In this way, PAC technology has allowed us to advance to smart relays and safety PLCs. One manufacturer has created a safety PLC that can be programmed with CoDeSys and meets safety-integrity-level (SIL) and performance-level (PL) requirements as high as SIL3/PLe.
Since CoDeSys can be programmed with C++ there is the capacity to do safety with C++. So, technically this small PLC is a PAC because of C++ capacity and higher memory capacity.
The other highlight of PACs is the increased remote input/output (I/O) capacity. PLCs may be single-racked and have limited I/O capacity, but PACs generally can handle 200 or more remote I/O nodes. This is dependent on which vendor system you choose, but the amount of I/O interface with PACs is higher than with PLCs. Much of this is due to networking, and, if the PAC has layered control, then it will have more network capacity.
PACs could be utilized with instrumentation that is Ethernet-compatible and skip the remote I/O racks. For instance, with IO-Link and a proper Ethernet server, a PAC can become an edge computer utilizing inputs, networking signals and controlling the machine.
As the trend has been and will continue to be, the PLC, PAC, local vs. distributed control system will continue to be a debate and under constant change. Why? Technology is advancing and industrial automation is becoming more open, more modular and more integrable. Advancing the PLC to the PAC is allowing this versatility to grow.
Imagine using a Linux-based system with container software like Docker. Picture breaking out the control inputs, the control processing and then the outputs to the machine, and the overall-equipment-effectiveness (OEE) and enterprise-network type of outputs. PACs will allow this kind of activity. The increased modularity pushes industrial automation forward into Industry 4.0 and more plug-and-play applications. Many controller manufacturers have offered container-type applications on their PACs. Others are following suit with Linux-based real-time control.
No matter the platform, machine builders have expanding options as PACs continue to develop. This is also exciting as far as adaptive automation. PACs allow the integration of AI modules and designs that can adapt dynamically.
