Open Systems Come to Process Automation |

Open Systems Come to Process Automation

Open Systems Come to Process Automation

By Benson Hougland, Opto 22

Products developed using open systems technologies are in widespread use throughout the commercial sector, providing a host of benefits to vendors and their customers. But the open systems movement has been slow to penetrate the often closed and proprietary world of industrial automation—denying end users, OEMs and system integrators the same types of benefits.

Spurred on by the Open Group and user demands, this situation is changing with the introduction of many new industrial automation products built upon and using open systems software and hardware. An example is the edge programmable industrial controller (EPIC), a relatively new product category, which makes extensive use of open systems and open source technologies (Figure 1).

Figure 1: Edge programmable industrial controllers, such as this groov EPIC from Opto 22, make extensive use of open systems technologies, giving users the freedom to integrate with other industrial automation components.

Let’s look at how new products, using open systems and open source technologies, are delivering economic, performance and flexibility benefits to end users, OEMs and system integrators. As it grows, the “open” concept is improving industrial operating systems, development environments, networking and remote access. The brain of any industrial automation controller is its operating system, so let’s start there.


Open Operating Systems

Consumers are familiar with PC and handheld device operating systems (OS’s)—such as the major Microsoft, Apple, and Google offerings—which are basically household names for OS’s sold by vendors. Far fewer are aware of open source options, such as the many derivatives of Linux.

“Open source” software of any type is licensed for free by its authors, and the source code is also made available so vendors and others can freely use it and even enhance it, with relatively few limitations. In direct contrast, “closed source” proprietary software is licensed for a fee, its source code is never made available, and the software may only be used in strict accordance with generally restrictive licenses.

Open source software has often been perceived as hobbyist-grade, while closed source would be considered for commercial/professional use. For the price of closed source, users expect continuous updates, heavy testing and ongoing developer support. Yet open source products also provide continuous updates, testing and developer support—and are widely implemented and often preferred due to their adaptability.

All processing devices, including automation controllers, require some sort of OS. Building upon an open source OS is a cost-effective way for vendors to focus their technical innovation on creating a solution instead of re-inventing an OS, which is why this approach has become an excellent choice for industrial controller vendors in the process automation arena. Linux in particular has found a strong following in many industrial automation controllers.



Open Programming Environments

Moving past the underlying OS, we next consider how end user developers create applications. For traditional automation products, developers were constrained into using exactly what the vendor offered. Upon selecting a product line to work with, the developer was effectively locked into that vendor’s ecosystem, sometimes called a “walled garden.” Software programmed in such an environment was rarely portable to other vendor’s products, and establishing data flows and mission-specific programming was often clumsy or not possible.

Once again, the open concept provides more opportunity and value. Open automation platforms have embraced the suite of IEC-61131 and other industry standard languages for logic controllers (Figure 2). These languages are similar to what many vendors have offered in proprietary products, but have been rolled up into a common standard of data types and configuration rules.

Figure 2 - The groov EPIC can be programmed with Opto 22’s flow chart language as shown; with the browser-based, flow programming environment Node-RED; or with virtually any modern programming language like C/C++, Python, Java using Secure Shell Access to the Linux OS. Future support for the IEC-61131 suite of languages is planned for later release.

End user developers benefit because they can create code that is more readily reusable and portable to other open products. They can concentrate more on the code functionality and focus, and less on the vagaries of various vendor products. In addition, it’s easier to hire personnel familiar with industry standard languages.

Beyond the real-time and data acquisition control level, developers are increasingly challenged with establishing data connectivity among devices, controllers and the cloud. For these types of tasks, browser-based flow programming tools, such as Node-RED, are establishing themselves as valuable resources.

This open source, browser-based visual programming flow editor is optimized for configuring data paths among devices, controllers and the cloud. This is done using pre-built nodes provided by device and software makers, making it easier to configure initially, and to re-use with a wide variety of projects and products.

For the most sophisticated users with applications requiring even more powerful algorithms, the answer is accessibility via Secure Shell Access to the Linux OS to implement their own custom code in Java, C/C++, Python or other languages. While relatively few applications require this extensibility, its inclusion in EPIC devices opens users to a full spectrum of automation features.

And with EPIC devices, these languages can all work together, passing data from one to another inside the controller.


Open Communications

All of this computing power located out at the edge of the automation network would be of little use without flexible connectivity, and fortunately the industrial sector in general, and EPIC devices in particular, have experienced great strides regarding openness in this area. Standard USB and other serial communications have a place for certain local connections, but the technology of choice in most applications is Ethernet, leveraged from the consumer market and bolstered with a number of industrial-specific protocols.

Ethernet tends to be high performance, cost effective and very familiar for most technology professionals. Many options exist for extending Ethernet over long distances and for making it more robust than consumer-grade implementations. As end users have demanded a move away from proprietary networking, most automation devices such as controllers, I/O, motor drives, smart instruments, Internet of Things (IoT) devices, and human machine interfaces (HMIs) are typically offered with Ethernet connectivity. These devices often feature embedded web pages for configuration instead of dedicated software.

It seems obvious now that the ease of use and economics of Ethernet propelled it to be the best open communication choice. Less apparent is that key to success for any device rests on offering a full range of possible communication protocols, which in turn is facilitated by the open OS underpinnings of these devices (Figure 3).

Figure 3 - Edge programmable industrial controllers use open system technologies to easily connect with field-based controllers and devices—and to laptops, PCs, smartphones and tablets via cellular, Ethernet or Wi-Fi networks.

In EPIC controllers, for example, communication flexibility can be provided by embedding support for communication protocols. For example, Inductive Automation’s Ignition Edge software is embedded in Opto 22’s groov EPIC controller, providing communication options including OPC-UA drivers to PLC systems (Figure 4).

Figure 4 - Built-in high-resolution, color touchscreen display on Opto 22’s groov EPIC gives users access to an onboard HMI, without the need for a local operator interface panel or PC. 

Open Remote Access

Industrial protocols are used to connect devices at the edge, typically local to the controller. The final link in this open source chain requires transporting data from the edge to a remote location, usually a control room or even a cloud-based database, which requires another set of protocols.

A popular open transport protocol for this purpose is message queuing telemetry transport (MQTT). There are several reasons MQTT is ideal for automation communications, starting with the fact that it is very lightweight and can be used with the smallest of devices. MQTT uses compact headers so only essential data is transmitted, and it is adaptable for working over slow and unreliable networks. It follows a publish-subscribe (or pub-sub) model, where data is only transmitted when it changes. The published data is received, but not stored, by a broker (also known as a server), and then is transmitted out to any subscribing clients. The entire concept is tailored to interconnect devices.

Another advantage of MQTT is that it operates over any TCP-based network using SSL/TLS for security, so it is a natural fit for the most popular industrial network, Ethernet. MQTT is a powerful tool for transmitting any size and sort of process automation data over common networks. Subscribing clients can be HMIs or databases, or really any other type of device or software with Ethernet connectivity (Figure 5).

As shown on the left diagram, communications among many clients and servers is complex with request-response methods. The open standard MQTT, depicted on the right, can be implemented in a publish/subscribe environment to provide extremely fast, highly secure, device-originating, two-way communications. 


Application Example

The end goal when using open source OS’s, development environments, communications, and remote access is to create best-in-breed industrial automation solutions that don’t lock the user into a proprietary and closed system. A typical municipal SCADA system shows how effective the open source approach can be (Figure 6).

The open source approach is an ideal method of interconnecting disparate SCADA control elements to a control room using existing Ethernet infrastructure.

Many municipalities operate distributed assets like tanks, lift stations, and booster pumps, each with their own local controls and monitoring. Often the local devices represent many makes and models, installed by different entities over the years and not following any particular standards.

Typically, it would require significant effort to architect and implement a poll and response system capable of interfacing these disparate elements back to a control room. However, this is a prime opportunity for an open solution.

Each location would require an open device. A tank level monitoring system might simply require gateway functionality to report data to the main control room, while more advanced systems could achieve two-way data transfer, allowing the control room to securely initiate commands to the remote location or directly control the local equipment. Some advanced EPIC devices include onboard HMIs and diagnostics (Figure 6).

Once these elements are in place and connected over any form of Ethernet infrastructure, developers just identify the data of interest, and it is linked from source to control room using MQTT. This linking goes in both directions, making it just as easy to send commands from the control room to each remote location.

Moreover, in both directions the data travels over an outbound connection from the client to the broker, which simplifies security. Since firewalls typically allow outbound connections over Ethernet, it’s not necessary to create virtual private networks or open ports in firewalls.

If the municipality in question is large and has hundreds of remote locations that require connection to multiple control rooms and many remote users, MQTT provides an ideal solution, as communication speeds are maintained at high levels.



Process automation industries have long been dominated by proprietary systems and vendors, which made sense as control technologies initially developed. Today’s reality is different, as significant commercial off-the-shelf technologies such as processors, memory and networking have advanced in ways that make these hardware platforms much more “open” and readily available for all sectors.

Extending this concept a step further is the ever-developing open software arena for OS’s, development environments, networking and remote access. Combined as open systems, these technologies may deliver economic, performance and flexibility benefits to both vendors and end users.

As end users demand more options, the economies of open source make it possible for many developers to design products meeting their needs. End users gain numerous options for integrating countless automation devices at the edge. And open development environments let users create and re-use code far more readily, enabling more tools to potentially drive operational success.

About the Author

With 30 years’ experience in IT and industrial automation, Benson Hougland drives strategy for Opto 22 products connecting the real world to computer networks. Benson speaks at trade shows and conferences, including IBM Think, ARC Forum and ISA. His 2014 TEDx Talk introduces non-technical people to the IoT.