PLC longevity could benefit from open architectures

Reading about namespaces, programming organization units (POUs) and function blocks is a bit like a kid learning English by spooning up letters from alphabet soup. Many people ask about the effects of the Industrial Internet of Things (IIOT) and Industry 4.0 on industrial automation, and they reference open programmable logic controllers (PLCs), and they talk about IO-Link, protocol converters, cloud interfaces and single-pair Ethernet (SPE).

It’s easy to look at what we can touch and feel and leave out the behind-the-scenes stuff: software. Software has its own changes related to Industry 4.0.

Get your subscription to Control Design's print magazine, free to qualified individuals in North America.

This year, Phoenix Contact will have interfaces set up with universal automation products built by Schneider Electric. Debuted in 2020, EcoStruxure was designed for the development and management of control systems. This was the beginning of changing IEC 61131-3 and extending it with IEC 61499.

There is a push for plug-and-play components in industrial automation. For an industry that is slow to change, it will be uphill in some instances.

Why? Industry still has 30-year-old GE systems requiring memory mirroring to allow for new systems to be put into place so that inputs and outputs can be converted in blocks.

This allows production to take short downtime periods for integration movements from old to new. However, this is the tenacious way of converting 1990s software control systems to new. This type of integration would also not be possible without software ideas to work around proprietary protocols and closed PLC platforms.

It is also a reason to think about PLCs and architectures. If POUs, namespaces and function blocks are utilized in architectures, then integrators have the capacity to program modularly.

Modular programming allows repeatability and reuse. This makes porting code between processors easier and development of multiple lines faster. Open PLC hardware would mean the software could go anywhere, regardless of platform. It also makes the data interfaces simpler. The push is to change architecture so that automation can focus on “speed, agility, flexibility and efficiency,” according to “The Road to Universal Automation,” by ARC Advisory Group’s Harry Forbes.

For example, Phoenix Contact’s PLCnext utilizes namespace assignments, and a generic robot interface might look like Figure 1. And Phoenix Contact already has UniversalAutomation.org (UAO) blocks for PLCnext.

The RobotFB can be the same but used differently (Figure 2). This makes software development easier because the person who is setting up the program tree and flow may not be working the robot code. But that person can use the robot interface based on knowing how the function block inputs and outputs work and where, when and how to call the robot function block.

How does this work for universal automation? It’s a beginning. If the robot function is prebuilt and the changes only must be made on the inside of the block, then the machine-level programmer can prebuild the code and then, when the robot code is finished, dump it into the block.

This does not mean the end of ladder logic, as a function block can be called in a ladder. It must be recognized though that PLC code is evolving, and complexity is changing.

It poses the question for operational technology (OT) to change with the times or to continue to lag. If OT integrators can show that they can save millions on integration time as proposed by PLCopen, which cooperates with the Open Process Automation Forum (OPAF) on the development of relevant standards and specifications, and manufacturing CapEx projects see the difference, and production has increased overall equipment efficiency (OEE), then time will tell.

The software and hardware changes in OT make it a prime time to develop a DevOps strategy in manufacturing, including modularizing code for performance, readability and reusability.