The Evolution of PLCs: What Will the New Normal Be?

Manufacturing and processing facilities still used hardwired relay-based control systems well into the 1960s. These were functional, but not flexible. Modifications and maintenance were time-consuming and resource-intensive. In the automotive industry, this type of infrastructure was a severe limitation.

That all changed when engineers developed the first programmable logic controller (PLC) in 1969 – a pioneering innovation that revolutionized the field of automation. The introduction of PLCs made it possible to implement and, if necessary, modify control logic using software. The PLC made it much simpler to program, modify, and expand control logic. For the first time, manufacturers were able to adapt readily to changing production conditions.

Over the decades, technological advancements, particularly in microelectronics, information technology, and communications have considerably enhanced the capabilities of PLCs. What were once very simple devices serving primarily as a replacement for relay logic have become complex control systems with integrated diagnostics, network connectivity, and the ability to process data in real-time. This evolution runs parallel to the development of technology in general. It also, however, shows how the increasing integration of production and information technologies in the form of software has built the foundation for industry 4.0 and the smart factory.

The virtual PLC: not the end, but rather the beginning

The last decade has seen increasing virtualization of systems and hardware. The transformation started with the introduction of the soft PLC. This was a marked departure from what was usually a direct connection between control software and its corresponding hardware. By implementing an additional software layer residing between the hardware and the operating system, a soft PLC enables the abstraction of physical devices. This makes it possible to deploy components such as hardware, software, storage, and networking equipment as virtual resources so multiple users can access them simultaneously. Virtualization also plays an increasingly important role on the level of the control systems. The introduction of the soft PLC has done away with the rigid coupling of hardware and control software, moving the control software up to the application layer of a PC operating system. This considerably enhances interoperability. And depending on the operating system in use, a soft PLC will still retain direct access to hardware.

The next step towards complete virtualization of automation hardware was accomplished by the virtual PLC. In contrast to software-based control systems (soft PLCs), a virtual PLC is completely abstracted. This abstraction and corresponding virtualization of the hardware is implemented using containers¹ or hypervisors², just as it is with other IT applications. The virtual PLC doesn’t care which device you run it on. You don’t install a virtual PLC on a computer, but rather in a container. Which computer that container is deployed on³ is irrelevant for the virtual PLC. But only so long as the container or hypervisor can provide as many interfaces to the hardware as the PLC requires. Except for latency considerations, it doesn’t really matter whether the PLC runs in the cloud, on the edge, or in a data center.

One of most frequently cited advantages of virtual PLCs over conventional automation control systems like soft PLCs is that a virtual PLC reduces the cost and time involved in procurement, wiring, maintenance, rolling out applications, and device administration. This saves resources across the board and prevents bottlenecks. All new technologies have aspects that warrant consideration, of course. IT security and safety are two key topics in this context (see IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems).

Let’s take a deeper look under the hood

The same functionality with less hardware, but more virtual. Software, cloud-ready. It sounds appealing — and this does truly look like progress. But this is fundamentally the same technology. It requires the same highly sought-after professionals to implement, the same tools and testing, and it comes with the same problems. It also introduces new factors to consider, such as managing the need for experts from a different background (IT vs. OT experts, for instance).

And there are more facets that should not be ignored:

• Which hardware requirements does the virtual PLC have with respect to the server that it will be running on?
• And how will this virtual PLC perform?

Because sometimes all you get is a clone of a physical PLC emulated with software that has just as much (or little) memory and supports interface standards just as poorly (or well) as its physical counterpart. You might experience the situation where a PLC requires enormous quantities of memory on the server it’s deployed on.

These are all things you have to ask the virtual PLC manufacturer or software vendor. Because in most cases it’s not just a single PLC, but rather a project with a larger scope. And suddenly what was once a little computer in the corner of the factory is now a complete data center that requires its own administration and maintenance etc. The same applies to questions about mechanisms for centralized deployment (versus point-to-point) or rolling out patches including the testing this requires.

The logical next step

The advantages of virtualization with respect to flexibility, costs, dealing with bottlenecks, and resiliency are undeniable. But when you talk about PLCs, one topic always comes up: cycle time. This includes real-time performance, in other words, the guaranteed ability to deliver results within a determined timeframe. PLCs — whether soft PLCs or virtual PLCs — read inputs, execute logic sequentially, and update outputs on a scan cycle. Each cycle, this repeats. And if you think about the basic premise of automation, which is all about carrying out discrete steps repeatedly, it makes sense.

But the demands placed on factories have changed dramatically in recent years. Yes, you still need the capabilities a PLC offers, especially when it comes to real-time requirements. But the manufacturing processes that are now being automated have become more complex and varied. Control software needs to keep pace with these developments.

What’s more important now are things like orchestrating the interactions of the various machines and programs, enabling interactions with AI-based services, and ensuring greater transparency in and with other enterprise systems. We’re talking about high-performance, highly parallel processing of big data with very complex interrelationships.

How can PLCs, which are not designed for a scenario like this at all, possibly be the right choice here? Modern IT solutions offer much more efficient options. The point is not to drive the PLC out of the factory and into the data center or the cloud, regardless of whether it’s physical or virtual. The goal is to use PLCs in a way that makes sense and in combination with IT functionality to give today’s manufacturers the ability to meet the demands of tomorrow.

The logical next step is to separate the two control tasks - hardware and process - which today are both programmed into the PLC. The PLC continues to control the hardware (e.g. robots, machines). But the processes (such as the sequence logic) are controlled by more efficient methods.

A look at modern production control

The IEC 61499 automation standard (Standard for Distributed Automation) has helped to make terms such as object-oriented, discrete event processing, and service-oriented architecture more commonplace in automation circles. But in daily operations, people still think inside the confines of what PLCs are capable of.

The easiest way right now, for instance, to tell a welding robot how to execute a spot weld, is to use a PLC. But is it necessary to use the same means to tell the robot at which location this process should take place? Because this is where things get tricky. Products change. Or maybe the company wants to produce different product variants on a single production line. The same applies to process control. Why would you make someone program a PLC to handle the logic or orchestration of multiple robots? Are there other solutions that could accomplish this at least as well? Ones that might even be more flexible and make it easier to implement changes, so that the declining number of PLC experts can spend their time on more important tasks?

Here as well, abstraction is our friend: The answer is decoupling product/process from hardware control.

Just like a virtual PLC has no need to know where the machine it’s running on is located, a welding robot only needs to know how to perform its spot weld. The product/process-specific parameter of “where” is provided from outside. Welding, fastening, clamping, and transporting items become abstract activities decoupled from the machine performing them, making these capabilities easier to utilize. The robot doesn’t need to know anything about the company-specific communications standards (which until now also needed to be programmed into the PLC).

In modern production control, capabilities are orchestrated, not individual machines. This gives companies new options and a high degree of flexibility and independence, also with regard to PLC programmers. And then there’s the contribution toward standardization: Vendors no longer need to program the in-house standards of their respective customers into individual PLCs. They just deliver a “thing with the ability to weld.” The production process is represented with full visibility in the IT layer above it. In IT, you call this type of approach hyperconverged infrastructure (HCI).

The evolution of the PLC runs parallel to the development of automation solutions. Rigid models are being questioned; the future lies in IT-OT convergence and hardware virtualization. Enabling disruptive innovation and fulfilling the demands of resilient production requires more than just virtualizing PLCs. There is currently no other technology that’s better at telling a machine what to do than a PLC. But when it comes to the flexibility of sequencing control, integrating with IT systems and AI, and providing intuitive user interfaces, solutions based on hyperconverged infrastructure are superior.

Ascon Qube

Ascon Qube lets you implement hyperconvergent infrastructures. It’s a vendor-neutral platform for the complete planning, optimization, and control of manufacturing processes using digital twins. This high-performance technology gives you more flexible production processes, creates transparency, and enables the easy integration of AI-based copilots.

Further explanations and definitions:

1. https://en.wikipedia.org/wiki/OS-level_virtualization ↩︎
2. https://en.wikipedia.org/wiki/Hypervisor ↩︎
3. https://en.wikipedia.org/wiki/Software_deployment ↩︎

Want to know more?

Ascon Systems - Digital Shadow

Hyperconvergence in manufacturing: increasing efficiency through IT innovation

The industrial metaverse: what to know about key technologies, correlations, and benefits