Dispelling Myths and Misconceptions about Modern Alternatives to Traditional PLCs: Part 1 – Introduction

To start, let’s outline the traditional PLC workflow:

1. Write the program using the PLC vendor’s proprietary desktop app and some variation of one of the IEC 61131-3 programming languages, usually ladder logic
2. Simulate the program and/or debug it online using a test PLC rack
3. Download the program to the actual PLC rack and debug it online (if needed) with everything connected, on-site*
4. Perform online debugging and program changes as needed in the future, on-site*

*Most customers don’t allow downloads or online edits to be done remotely, as you wouldn’t be able to see the effects and communication could be lost during the download/edits.

To be clear, the traditional PLC approach is perfectly fine, and should be credited for all its successes.

Now, there have been discussions going on for decades about alternative approaches, but more to the point, there have been a LOT here lately on LinkedIn. There has been fiery discourse, and it shouldn’t be that way because most of the proposed alternatives are geared towards making industrial automation easier, more capable, and more reliable.

What alternatives am I talking about? Well, there are a lot of different ideas being thrown around, but ultimately all these solutions fit the template of:

1. Creating a control program using a programming language (IEC 61131-3 or otherwise) that
2. Runs somewhere (a PLC, an edge computer, an on-premises PC/workstation/server, a cloud server, etc.) and
3. Utilizes I/O somewhere (on the same device, an I/O gateway, a PLC, etc.).

With that in mind, let me frame the goals of these alternatives:

• To make life easier!
• To complement and enhance existing approaches.
• To be just as the wording I’ve used–alternatives, not replacements.

What does that look like? Well, let’s re-imagine some of the details of that original workflow:

• Write the program however you’d like without being locked-in to a particular vendor.
• Creating a Continuous Integration/Continuous Delivery (CI/CD) pipeline as part of the debug process to ensure that all future program versions function properly.
• Speaking of versions, using revision control systems that allow you to not only beautifully see the changes made in every version, but to cherry pick the exact changes you want to keep and discard.
• Managing an entire fleet of PLCs using a web browser from anywhere in the world, without having to deal with VPNs, virtual machines with old versions of PLC software, etc.
• Being able to utilize more advanced coding tools such as static analyzers to prevent fault-causing code before it even hits the hardware.

Having said all that, let’s start by lightly addressing the most important counterarguments:

Myth #1: These solutions are being pushed so that software developers can take jobs away from PLC programmers, automation engineers, etc.

Absolutely not…it’s all about bringing the best practices and conveniences from the IT and software worlds to the OT world to make everyone’s life easier! Modern approaches will enhance the capabilities of those already working in automation. As some have expressed, people who have only worked in software would not understand the complexities faced in automation.

Myth #2: Only PLC programming languages are suitable for industrial automation

Myth #3: Only PLCs are suitable for industrial automation

Neither of these statements are true, and I will dig much deeper into the reasons why in the following parts of this series. But in short:

• Computer programming languages are used everywhere, in everything, in all sorts of critical applications, and even in safety applications. There aren’t necessarily inherent problems with a programming language, it all depends on the implementation of that language.
• The suitability of any particular hardware depends on the components selected, manufacturing process, design, QA/QC, etc. Any type of device can be made to withstand industrial conditions and work for 40 years straight.

Before closing out this part, consider these questions:

• What hardware, operating systems, and programming languages are used in mission-critical applications like automobiles, avionics, medical devices, military/defense systems, satellites, etc.?
• What hardware, operating systems, and programming languages are used inside HMIs, industrial routers/switches/firewalls, protocol converters, even PLCs themselves?

The answers may surprise you. Stay tuned for more. Part 2 will address programming languages specifically, i.e. Myth #2.