Hardware independence is what PC-based control promised back in the 1990s. You can run any software on any hardware you choose. Sound familiar?

Comparing industrial computers to programmable logic controllers (PLCs) is an unwinnable argument, in my view. The number of proponents of standardized programming, which can run on any hardware, is wild and free. Part of the argument is that you can choose the hardware to run on, and, if you need to change, the software goes with it.

That hardware platform has a large surface area and can include commercially available single-board computers like Raspberry Pi and Arduino. Suppliers have built solutions around these platforms and can run IEC software.

For me, when a control system is in place, regardless of the platform, it becomes a single-source solution.

The big area of support comes from training so that the maintenance staff can troubleshoot and get processes back up and running. It’s that darn 3 am trouble call that dictates how you handle the outcome.

PLCs have been around much longer than IPC control systems, although distributed control systems were computers of sort running Unix in the early days. With Windows being standard fare on the factory floor for HMI/SCADA, solutions such as the DEC VAX/PDP series of minicomputers have been relegated to the museum.

What the PLC has done for automated control systems has been well-documented. IPC systems, while not new, don’t get the kudos they deserve in some arenas.

Windows 95 really changed the trajectory of personal computing in the industry. People became programmers, which was witnessed by the injection of computer languages into industrial control systems. Python and C++ are prevalent, as well as Visual Studio (C#).

But, hang on a minute, a modern-day PLC has so much capability over and above ladder logic. Supporting IEC-61131 languages, as well as loadable libraries compiled and written in the aforementioned languages, kind of makes them more like an IPC, but with the ability of providing a normal approach to troubleshooting the process when it fails.

I was just reading an exposé on how you can extract data values from a PLC using REST, JSON and gRPC. While not control-based, it is an example of how PLCs are interfacing with current commercially available protocols and data extraction methods.

An IPC has the same options available.

Get your subscription to Control Design’s daily newsletter.

The training and tools needed to troubleshoot current systems that employ various languages and libraries are continuing to develop. Augmented reality is a methodology with promise.

Back in the good old days, troubleshooting a system meant getting the drawings out and having a meter in hand. Relay logic created great troubleshooting methodologies and approaches to getting to the root cause.

When the PLC and software arrived, we all thought everything would be easier to troubleshoot. While basically true, the same approach still needs to be employed. If the power-on light is off, it probably isn’t a limit switch.

Regardless of whether the control system is a PLC or an IPC, the software inside monitors the system. Both would control a fault light prompting the operator or maintenance person to investigate the HMI to determine what the fault is.

Having said, that we don’t care if that data came from the control system using Windows or Pi; we just care that the data is there. We just need to know how the data got there, should we need to dive deeper into the communication.

Using an IPC delivers a different subset of what could be wrong than a PLC does. With the continuing advancement and integration of commercially available technologies, our skill set needs to keep pace.

Newer PLCs can support multi-CPU core architectures, where one of these cores can support a Windows installation. This can bridge a gap between a PLC and an IPC.

With blurred lines between IPCs and PLCs, the task selection criteria becomes more about software and what it runs on.

What is common however is the fact that IEC-61131 software is becoming more prevalent in current process solutions. Many vendors have used the main premise of IEC and created their own flavor of control software. The advent of virtual PLCs is creating another future challenge.

The typical automation infrastructure is being redefined using the hardware-independent virtualization of a PLC. This provides advantages over current solutions by deploying a PLC onto a server multiple times and having access to each one of them from anywhere.

Whether you believe in the hardware independence of IPCs or virtual PLCs, or you believe in the single-source norm of vendor-driven PLCs, our world is better off for it all.