Open Programming Languages Flourish in the Industrial Space

For many years in the industrial automation sector, end-user petitions for openness and flexibility had been at odds with what suppliers were willing to offer. Especially in the case of digital technologies, which have been available for more than five decades, hardware and software was often specialized, and even proprietary. However, this has been improving over the years to meet end-user needs, first with hardware, and now with software.

There are many good reasons digital technologies applied to industrial automation have been slow to embrace more open ecostructures, especially for direct control of physical devices. Because industrial applications exist in demanding environments, must run reliably and are essential for safe operation, it is reasonable that general-purpose solutions simply would not be up to the task.

Yet the nature of industrial automation projects has evolved. Designers have an increased need for customization, along with the ability to support extensive data handling and analytics. They are calling for modernized development options, and the ability to take advantage of interoperability and design portability. This push is coming from end-users, as well as systems integrators (SIs) and original equipment manufacturers (OEMs), all of whom would benefit from updated ways of performing industrial automation programming.

For these and other reasons, open programming languages are flourishing in the industrial space, providing designers with the opportunity to create next-generation solutions, while maintaining the dependability of more traditional technologies.

The Origin of Exclusivity

Before looking forward to open industrial language options, it is instructive to glance back at the history of their formation. Pre-digital automated projects were originally created by hardwiring relays, switches, buttons and indicators. When these functions were digitalized into what we know as programmable logic controllers (PLCs), the programming methodology consisted of constructs similar to electrical wiring diagrams, such as ladder logic, along with other basic instructions needed for logic and handling of associated input/output signals.

Every supplier created PLCs and integrated development environments (IDEs) with their own style, not directly interchangeable with other suppliers (Figure 1). Because suppliers controlled the software environment and the physical hardware, they were better able to assure users that the entire platform would perform to meet industrial requirements. But users became fairly locked-in with certain suppliers due to the difficulty of switching to other options.

Figure 1: Traditional PLCs, like the AutomationDirect Productivity family, with dedicated development environments are still useful for many industrial automation purposes, but many developers are looking for options to streamline design efforts and support increasingly data-intensive applications.

Meanwhile, as the intelligence and capability of controllers and field devices skyrocketed, users began looking to access and act upon the growing availability of data. Classic automation languages were not as strong for this task, which is much better handled with more modern non-industrial languages.

The traditional PLC paradigm still exists today, and even considering the downsides, this environment remains viable and useful for many—perhaps a majority—of applications. But just because something is workable doesn't mean it can’t be made better.

First Steps on the Path to Industrial Openness

Moving away from the traditional and proprietary PLC automation concept has been a slow process, but many suppliers have recently incorporated functionality or created products to support openness and readily available commercial off-the-shelf (COTS) technologies. From a hardware perspective, both PCs and Ethernet have become the preferred and open hardware basis for visualization and communications, respectively. Sometimes it is possible to use general-purpose versions of these technologies, but usually designers will lean toward industrial-grade options.

For industrial control software, there have been a series of developments supporting openness:

Standardized IEC 61131 languages
Common IDEs, such as CODESYS
Open microcontroller platforms (such as Arduino) able to use modern languages, such as CircuitPython and C++

IEC 61131 languages. A first step toward industrial programming standardization was the creation of IEC 61131 in the mid-1990s, with improvements made in subsequent revisions. Today, this standard defines concepts such as data types, and programming styles such as ladder diagram (LD), function block diagram (FBD), structured text (ST) and sequential function chart (SFC). Each style has strengths and weaknesses, and while many manufacturers aligned with this standard to a degree, it has remained largely impractical to port code from one vendor platform to another.

CODESYS integrated development environment. Portability is sought after by end-users and SIs to provide better flexibility when selecting run-time platforms. This enables them to reuse their proven work on subsequent projects to minimize risk. They can also use customer-preferred platforms, or switch platforms if needed due to supply chain issues.

One approach for supporting end-users in their quest for portability, while providing benefits for platform suppliers, was the development of CODESYS. CODESYS is based on the IEC 61131-3 programming languages, and it can be incorporated by suppliers into their controller platforms. Because it is hardware-agnostic, users can develop code in a common IDE and then deploy it to the platform of their choice. Software libraries are available for free or purchase.

CODESYS makes it easier for suppliers to adapt their platform to meet standardization needs. It has been around for many years and has gained good acceptance in European and Asian markets, and it is increasingly used in North America. Users only need to become familiar with one IDE, simplifying the learning curve. They can also take advantage of contributions and feedback from a large global community of knowledge. While some advanced capabilities such as reusable function blocks are possible, there can be some constraints on ready access to certain hardware-specific features.

Open microcontroller programming. An even newer trend is for designers to select COTS microcontrollers—such as Raspberry Pi and Arduino—in either general-purpose or industrially-hardened versions. These controllers allow the use of more modern IT-based programming languages, such as C++ and CircuitPython, the latter an open-source derivative of MicroPython.

These text-based programming languages are more familiar to designers entering the workforce, as compared with traditional IEC 61131-3 languages, and they are also far better for heavy math and data handling (Figure 2). In some cases, workflow and version control may be supported.

Figure 2: Industrial control applications can benefit technically from platforms supporting the use of modern text-based programming languages, such as C++ and CircuitPython, and these languages are familiar to many designers entering the workforce.

Open microcontrollers may not fully take over control duties handled by PLCs, but some versions are available in a form factor compatible with proven PLC I/O modules. This provides another option for developers to tailor their designs to specific application needs, while providing enhanced data connectivity and integration with supervisory systems.

Getting on the Open Road

Industrial automation application and project needs vary dramatically, and end-users often look for a simplified interface so they can support existing systems. OEMs need to be able to reuse code and functionality so they can deploy it for ongoing work. SIs also want an easy way to expand on a proven code base, along with the ability to incorporate useful external libraries. And all these groups would prefer to learn one common IDE to streamline their workflow.

Open languages often mean a reduction of software and licensing fees for end-users, and other efficiencies as designers scale and adapt their work. When developers have access to more communications protocols and standardized computing options, they have more freedom to create valuable solutions.

However, even with all this said, the traditional PLC is not going away soon. Traditional PLCs with dedicated IDEs will continue to make the most technical and economic sense for many projects. Some users will choose to only use platforms based on IEC 61131-3 languages and CODESYS to support a large existing technology base in the most open way possible. Other users developing advanced logical and data processing projects will lean toward platforms able to run modern IT-based programming languages (Figure 3). In some instances, both technologies may be deployed for one application, with a PLC for real-time control and an open platform for higher-level tasks.

Figure 3: While traditional PLCs with dedicated IDEs are not going away any time soon, some users are moving toward PLCs that run more open IDEs such as CODESYS, or industrial controllers, such as the Arduino-compatible AutomationDirect ProductivityOpen family, which use modern IT-based programming languages.

Industrial automation technologies will continue to evolve based on both the technologies available, as well as on user and project needs. End-users, OEMs and SIs are best served when suppliers can offer a range of platforms meeting their requirements, with a focus on providing openness.