When it comes to controllers, manufacturers and industrial companies are often inclined to leave something that works well enough alone. After all, with the right maintenance, programmable logic controllers (PLCs) can run uninterrupted, faithfully controlling processes and performing other essential functions for years without needing to be replaced.
But all equipment does reach the end of its lifecycle eventually. And sometimes, a company might want to add new features to enhance system control. In that case, the company will start looking at PLCs and asking system integrator partners what their upgrade path should be and whether they should add new technologies to the mix.
Often, the selection is straightforward. If a plant has been using a particular PLC family for a dozen years, there is likely little point in migrating to a software based controller running on an industrial PC. “You need to take into account support, spare parts, and cost of ownership,” says Mark Brado, automation engineering manager for JNE Consulting. “You don't want to sell them something that's more elaborate than they need.”
Frank Burger, senior automation specialist at Avanceon, concurs. “Most of our customers have an installed base and it's important to them to manage their spare parts inventory. They also need to manage the training needs for their technicians who have to maintain this stuff long term,” says Burger.
For these reasons, manufacturers tend to look for control technologies that, though they may not be perfect, get the job done reliably. Despite industry’s reliance on the tried-and-true, it pays to pause and review controller options before the need to upgrade arises.
Half a century ago, PLCs were developed as a solution to the limitations of electrical relay logic systems. They allowed engineers to develop, modify, and expand the functionality of control systems through software, rather than hardware, changes. This meant no more rooms full of wiring. Now, in the 21st century, PLCs continue to be prized for their steadfast process control reliability.
Over the years, PLC manufacturers such as Rockwell, Siemens, and Mitsubishi Electric added capabilities to PLC functionality, including integrated servo and drive control, network communications, advanced process control, and configurable and event-based I/O scanning. As such sophisticated functionality began appearing, the industry differentiated these advanced controllers from less complex PLCs, coining the term “programmable automation controllers” (PACs). Since the introduction of the PAC term in the 1990s, manufacturers have used it to distinguish their advanced controllers from their simpler PLCs, although the boundaries have blurred and the terms are often used interchangeably. PLCs and PACs serve the same approximate purpose, but PLCs are typically specified for basic discrete control, and PACs are used when complex features or infrastructures are required.
Most classic PLCs use a memory-based form of programming, where the addresses are tightly coupled to a physical memory structure, says Nate Kay, senior project engineer for Martin CSI. “Whereas with PACs, you don't have to worry about that. [PACs] are intelligent enough to let you focus on writing in the programming language, and they handle memory management in the background,” says Kay. PACs also allow tag-based programming, which increases flexibility and scalability by allowing tags to be assigned to functions before tying to specific I/O or memory addresses.
Classic PLCs still have their place because they're cost-effective, simple, and can run for years, says Kay. They can also be easier for someone from a non-controls background to maintain and troubleshoot. “PACs are often well-suited for controlling larger processes and integrating things like safety, motion, distributed I/O, and network communications,” he says. With PLCs, you would generally have to add hardware modules to perform those types of tasks.
Today when you see the term PAC, it’s usually referring to the higher-end product within a common product line, says Burger. Because the PACs and PLCs from a supplier often use the same hardware, just with different software capabilities, most people tend to call them PLCs.
Doing shop floor control on a ruggedized PC called an industrial computer is not a new concept. The Allen-Bradley SoftLogix line, which ran on the Windows 7 and Windows Server 2008 operating systems was a prominent example. Software-based PLCs feature the same programming environment and firmware as a physical PLC, says Burger. “A soft PLC is programmed and run the same way as a PLC, it's just hosted on a computer instead of on its native hardware,” he says. But PCs can run multiple applications and are generally not dedicated controllers. As a result, some suppliers have discontinued their sales of such products. For example, Allen-Bradley has sunsetted active support for SoftLogix.
Another issue to be aware of with industrial PCs (IPCs) are the updates and patches required, as with any PC. Burger says IPCs are not necessarily a technology “you expect to run trouble-free for 10 years without a power cycle. Which is exactly what you do expect from a PLC or PAC. We're replacing older PLC solutions that were installed upwards of 30 years ago, and it's still the original hardware. You don’t have that in a PC environment.”
Andrew Abramson, director of client success at Grantek, has a similar perspective. “For the most part, we see industrial PCs being removed from the plant floor wherever possible, and those functions migrated to a centralized virtual environment in combination with thin clients on the plant floor,” says Abramson.
The virtualized environment could be either an on-premises data center or in the cloud. The drivers for these Physical-To-Virtual (P2V) migrations come from IT and include future-proofing, reducing the hardware footprint, better backup/redundancy, lower mean time to repair (MTTR), enhanced security, and a centralized management location, adds Abramson.
IPCs are most definitely used on the factory floor, but these days usually as an operator interface with a thin client. “The PLC is making all these decisions kind of in a vacuum without a human. But in reality, there is a person there and he wants to be able to start and stop the system and make, for example, vanilla instead of chocolate,” says Burger. The operators need to be able to observe what the process is doing at any given point in time. They need a window into the process be able to make changes. The role of the industrial computer then is as an HMI to provide that window into the process. Typically, you have a PLC, working in tandem with an HMI on an industrial computer to give that full functionality.
On the other hand, IPCs have some advantages as controllers, according to Kay. “You can run databases, protocol converters, and recipe managers [on an IPC]; you could even run your SCADA and MES software on the same industrial PC that you're using as the automation controller.”
But this comes with the tradeoffs inherent to the PC platform mentioned above. “The Windows and Linux operating systems are not optimized for high performance in deterministic industrial applications,” Kay says.
Burger notes that IPC-based control fits best in a specialized R&D-type of environment where the requirements are not specifically known in advance and are subject to change dramatically. “There, you need a platform that is able to do wildly different things over the course of time,” he says. In that case, the system might be out of service fairly quickly, [based on] the time it takes to complete a proof-of-concept, say a year or so. And “if you want to develop a program in C++, or C#, for example, you're not going to be able to do that on most PLCs or PACs,” he adds.
IPCs are also used in cases where there may not be an existing server or network infrastructure to support a thin client architecture. They’re also used where processing power is immediately needed, such as machine vision, adds Abramson.
The bottom line is that control systems are not one-size-fits-all. A modest traditional PLC may ably meet the requirements for a small packaging machine, whereas a PAC with advanced functionality may be required for complete packaging line control.
“Every system is unique, and when specifying a control solution, we always start with considering the user and functional requirements,” says Abramson. If you’re facing an upgrade, enlist the help of a trusted system integrator partner to weigh the costs and benefits of the different architectures including initial capital investment, ongoing maintenance costs, technical sophistication of the client, and the risks or functionality inherent to those technologies.
