Software-designed automation is a mindset change from hardware approach

Nathaniel Scroggins, product marketing manager, connection technology, Balluff: The primary focus of software-defined automation is to automate processes with software infrastructure in mind. This is a mindset change for an automation world that has gotten used to designing with specific hardware as the primary focus. That approach can lead to a lack of flexibility and interchangeability within a system’s architecture.

The SDA approach emphasizes flexible, open-source, universal protocols and agnostic platforms that can use any vender's hardware, making it easier for users to manage and scale their systems over time. This approach also opens the door for more rapid deployment and troubleshooting of assets.

When designing with a hardware-defined approach, you are not always providing the user with the ability to make changes as their needs evolve or their systems need to scale. This can happen often when using proprietary protocols or hardware/software combined products that are unique to that vendor. We see examples of this when looking at programmable logic controllers (PLCs) that are locked down or don't have the ability to connect to IT networks, causing the user to have to change PLCs and reprogram the machine to open it up to their network or even to just make simple changes to machine configuration.

Hardware-defined automation is rigid and requires manual/physical adjustments, whereas software-defined automation provides users with the ability to make more fluid and quick changes when necessary.

What are the primary benefits of software-defined automation?

Nathaniel Scroggins, product marketing manager, connection technology, Balluff: The primary benefits of an SDA approach lie in its ability to provide and maintain flexibility and interchangeability. Users' system architectures are all continuously evolving and scaling as we push deeper into an Industry 4.0 landscape. This means that having the ability to swap out devices or systems as needed with minimal impact to the existing environment is important.

Which standards and protocols will be affected most or increase/decrease in use because of software-defined automation?

Nathaniel Scroggins, product marketing manager, connection technology, Balluff: We are seeing a rise in the use of OPC-UA, message queuing telemetry transport (MQTT) and representational state transfer (REST) application programming interfaces (APIs). These IoT protocols are universal and allow devices and systems to communicate throughout a system architecture more freely and easily. Specifically in regard to SDA and REST APIs, I am seeing a large increase in use as we continue to integrate, control and manage software systems on-premises and in the cloud.

It is likely that we will see a decrease in any proprietary protocols that box users into a specific vender or hardware family. Users are more acutely aware of this now more than ever as they are striving for systems environments that remain mostly agnostic, flexible and scalable.

Which components will see the biggest impact from software-defined automation?

Nathaniel Scroggins, product marketing manager, connection technology, Balluff: Edge devices will be most impacted from the use of SDA. Users are looking for ways to quickly get devices onto the network and integrated into their system architecture. Edge devices that utilize IoT protocols and open communication methods, like MQTT, OPC-UA and REST APIs, allow users to get data to parts of their architecture without needing to change much within a system. For example, an edge device could be connected to an open reporting software via MQTT or REST APIs—displaying real-time data from sensors monitoring the conditions of assets within a machine.

Tell us about your company’s state-of-the-art product that involves software-defined automation.

Nathaniel Scroggins, product marketing manager, connection technology, Balluff: Balluff's Condition Monitoring Tool Kit (CMTK) is an edge device with a free, open-source software pre-loaded onto it that acts as a quick-start gateway to a user's existing network architecture and provides a SCADA-like environment to deploy and monitor process sensors. The CMTK device utilizes the IO-Link protocol for sensor-level connections, which is globally accepted by automation users. It doesn't tie users to proprietary protocols, meaning the device is sensor-agnostic. It acts as a gateway to a user's network by offering MQTT, OPC-UA and REST API communication methods to connect to various other systems. The software is built on Grafana, offering quick deployment of customizable dashboards to display sensor information. It also provides access to Docker and Node-Red via the optional SD card slot for more advanced configuration.

This device is most impactful when used to step customers into SCADA-like monitoring functionality via the software, but it can easily be reconfigured to a data aggregation and monitoring gateway that can push data into a full SCADA or PLC system, which enables control and automation. The device remains completely open, and the user owns their own data, which can live on the device via the InfluxBD or be passed to other user databases.