Developed in the 1960s as a replacement for the widely used relay control system, programmable logic controllers (PLCs) have remained the core industrial controller technology, even as it has expanded into programmable automation controllers (PACs) and industrial PCs (IPCs).
The primary reason behind the development of the PLC was to ease to the process of making changes. Relay control systems were hard-wired, not coded, meaning that any changes to a relay-based automation system required physical rewiring. If any errors were made in the relay wiring, hours of troubleshooting were typically required to compare schematics to the actual wiring to find the problem.
Basic computer technology of the era was first attempted as a replacement for relay control systems, but they were unsuitable for industrial environments—an issue which persists today for general-purpose computers.
PLC origins and development
The technology widely recognized today as the first PLC—the Modicon 084— was developed by Dick Morley for General Motors in 1968. The name Modicon was derived from the words “modular digital controller” used to describe this new development. Some of the now common controller features introduced by the Modicon 084 included: a hardened design that made it viable for use in industrial environments, modular I/O (inputs/outputs) that could be added as needed to connect field devices to the controller, and the development of the ladder logic programming language still in wide use today. Ladder logic resembles the relay contacts and coils that were familiar at the time of the PLC’s introduction, making it easy for engineers and technicians to switch to this new method of control programming.
The PAC difference
While featuring several differences from a PLC, PACs are often referred to as PLCs because they perform many of the same functions to control automated processes. Also, some higher-end PLCs have many of the same features common to a PAC.
Why IPCs?
As the name implies, industrial PCs are PCs designed for industrial use. In other words, they are not designed solely for industrial control programming like PLCs and PACs but are equipped and capable of being used for such purposes.
Other ruggedized features of an IPC include:
- Operating temperatures can range from sub-zero up to 60-85°C.
- Metal frames construction and resistance to vibration
- Protection from electromagnetic interference and voltage surges.
With their computing components and multi-core CPUs, IPCs can be used to run machine/line control programs as well as other computing programs as needed. Users can run databases, protocol converters, recipe managers, and even SCADA and MES software on the same IPC used as the automation controller.
Since IPCs typically run an operating system like Windows or Linux (i.e., operating systems not specifically optimized for deterministic industrial applications), this has led to some debate over the reliability of IPCs in comparison to dedicated controllers such as PLCs and PACs. However, IPC suppliers and numerous users regularly attest to their dependable reliability in industrial applications.
- Panels: These are combinations of an HMI and an IPC for machine or line control.
- Box or embedded PCs: These compact IPCs are designed to be rail mounted into discrete systems and integrated with other systems in the enclosure.
Just as PACs tend to be preferred over PLCs for more complex automation tasks, IPCs are often preferred for complex applications due to their advanced computing capabilities, and for ease of networking the controller with asset management and other enterprise systems.
End user and integrator insights
To get a sense of how end users and system integrators view the controller technologies they work with as controller functionalities adapt to industry’s digital transformation demands, we surveyed both groups to get a sense of what advances in controller technology they found most important, which type of controller they prefer to use and why, their thoughts on the burgeoning field of web-based controllers, and their recommendations for selecting programmable logic controllers (PLCs), programmable automation controllers (PACs), and industrial PCs (IPCs).
This is a particularly noteworthy response for two reasons: 1) Less than 20 years ago, many engineers were against the use of Ethernet on the plant floor due to its lack of determinism and concerns about direct connections to enterprise networks and the kinds of oversight into day-to-day plant operations that could entail; and 2) Cybersecurity concerns.
Having heard engineers say things such as: “Ethernet will come on to my plant floor over my dead body” and “Ethernet is not a plant floor network” in the not-too-distant past shows how much industry’s opinion of Ethernet has changed in a relatively short amount of time based on our survey’s results.
Much of this change is likely due to a confluence of factors, most notably the prevalence of Ethernet for all personal and business communications—whether it’s via a mobile device or office computer—and the accompanying realization that factory floor networks cannot continue as completely isolated operations akin to a black box when it comes to enterprise-level connections. Production data and the information insights they provide are too critical to the ability to continuously improve operations and adjust business strategies in relation to production and supply chain operations. And controllers, as the brains of automated devices, hold and process significant amounts of this critical data.
As for cybersecurity, though significant disagreement remains on how best to secure plant floor technologies, industry has largely accepted the idea that cybersecurity will remain an ever-moving target that companies will have to continuously adjust to. The idea of not connecting plant floor systems to higher-level networks is largely viewed as incompatible with the basic requirements of the modern industrial environment. The fact that roughly one third of both end users and integrators agree that high-speed Ethernet is the best thing to happen to controllers since their development underscores this reality.
Further supporting this development is that 20% of end users and 14% of integrators note wireless capabilities as one of the most significant advances in controller technology. These results put wireless in second place to Ethernet among end users and third place for system integrators. Because wireless is a form of Ethernet communication, it could be surmised that 49% of integrators and end users view Ethernet as the most important controller advance.
This puts “increased memory” in second place, with 19% of integrators and 16% of end users—for a total of 35%—citing its importance, followed by “smaller footprint” noted by 32% (18% of end users and 14% of integrators).
Controller preference
When it comes to stand-alone controllers, such as PLCs, PACs, and IPCs—not embedded micro-control units—there is a general preference for PLCs according to the results of our survey.
Among integrators, 50% prefer PLCs, with the remaining 50% evenly split in their preference for PACs and IPCs. End users, however, have a much stronger preference for PLCs (75%), followed by a 17% preference for IPCs and just an 8% preference for PACs.
The wide disparity in preference between PLCs and PACs among end users is intriguing given that PACs are essentially PLCs with added features such as greater programming language support, more memory, and interoperability capabilities. The preference for PLCs comes down to two issues: expected reliability and greater familiarity with PLCs, which together account for 65% of the reasons for end users’ PLC preference. The numbers associated with those two reasons were similar for integrators at 67%.
Despite the advantages provided by PACs, 43% of integrators said they recommend PACs over PLCs less than 25% of the time. The primary reason for this is that many industrial applications require only basic PLC capabilities, as the extended capabilities of PACs are better suited to more complex automated systems. This reasoning is supported by the fact that the top two reasons integrators recommend PACs are for their extended programming capabilities (50%) connectivity features (25%). Another reason integrators cited for their PAC preference was “customer preference” for PAC technology.
The fact that PACs and IPCs tied for second place in the estimation of integrators deserved a closer look at the reasons why. The top factor for PAC preference among integrators is the technology’s I/O capabilities, which allow for tracking and control of more I/O points than PLCs. For IPCs, two features tied for the top preference among integrators: virtualization capabilities and greater networking options.
Virtualization of controllers is a growing trend in industry for its ability to provide the required control capabilities while taking up less space, increasing application longevity—often by a factor of 2x, and reducing the number of physical controllers to manage, repair, or replace.
Recommendations
A common response from both end users and integrators across all three types of controllers was to ensure the availability and responsiveness of support. Given the purpose of controllers, this response is not surprising because, if the controller goes down, so does your production on the machine or line using that controller.
Some respondents noted their preference for local support given the importance of controllers to production operations, but local requirements are not generally viewed as critically important as it was once due to remote access capabilities for troubleshooting and repair. As a result, local support requirements are increasingly a factor of the size, complexity, safety, and criticality of your operations.
Beyond the importance of reliable support, recommendations for PLCs, PACs, and IPCs differed.
For PLCs, one end user said: “Communications options are getting better but are often a stumbling block when trying to integrate a larger system. Make sure there are enough communication ports and options available for both the current configuration and for future expansion.”
Another end user suggested that perspective PLC buyers should look closely at details such as processing time, communications options, the number of allowed connections, I/O limits, temperature, and vibration specs. This user added that it “helps to standardize on a brand as the IDEs (integrated development environments) can have a steep learning curve and are expensive to maintain.”
PAC end users recommend investigating the extra features of PACs closely before purchasing. One end user said: “Built-in IEC languages are a big plus and PACs have many other interesting features, but not all features are desirable in our field. There is a lot that goes into PAC price/performance calculations! Some vendors charge extra for every feature which is not desirable.”
Integrator respondents agreed with this sentiment recommending that users ensure that the PACs they are considering have the appropriate options for the task and environment.
The widest array of advice from end users applied to IPCs.
One end user said to make sue the IPC can be locked down because “many people are familiar with PCs and like to tinker with them.”
As with any controller, obsolescence will be an issue over time. But with IPCs it can be an issue faced more frequently based on the operating system used. One end user noted that they are “stuck on a non-updatable version of an operating system that will not integrate with the current network.”
Another end user suggested working with the IPC supplier to ensure correct implementation of security features. One end user said they found IPC cybersecurity requirements to be more complicated than PLCs.
