Implementing a vPLC solution over 5G network
As a new joiner at Accenture, before I’ve got my first interaction with a client, I received the mission to implement a “Virtualized PLC solution” using a 5G network we have available on our Innovation Center in Garching, Germany.
The original goal was: Let’s create a demo using the 5G technology as a use case for the industrial automation environment.
These were some of the questions we had to answer:
- How fast is the 5G network to control a production line over a wireless connection?
- How reliable is the connection to control a device remotely?
- How many devices could be connected to this network without compromising the performance?
First of all, let’s get started talking about the advantages (and disadvantages) of a PLC-based automation:
1. Automation logic and integration is (most of the time) dependent on a unique manufacturer
Most PLC manufacturers have their own software, programming language, and protocols to design and upload code to their devices. This is supposed to guarantee some level of stability and security in the industrial context, as these operations must be fail-proof and very reliable in terms of stability and efficiency, but it comes with the cost that integration between other manufacturers is complex (when it’s possible) and will add another set of tools, software, etc, from other manufacturers to deal with this.
2. Maintenance cost to update workflow logic and parameters
Every time a new software upgrade must be applied, it requires a physical replacement of an SD card with the newest version of compiled code. If you have an industry with multiple PLC installations, you have a production downtime and human effort to go through all devices to replace the code, considering everything goes well on your first test, if not, all this effort must be applied again to fix the problem.
3. Real-time data analytics and visualization
Nowadays it’s possible to have real-time dashboards for operational and analytics purposes based on SCADA systems. These systems are usually installed into level 2 (plant supervisory) of the following diagram, which is a general model which shows functional manufacturing levels using computerised control.
PLC installations based SCADA system is complex in terms of hardware units and dependent modules. As the system is complex, it requires skilled operators, analysts and programmers to maintain SCADA system.
When we decided to introduce Open Source Software into this context, we started to look ahead into the possibilities to extend, integrate and customize PLC installations that don’t necessarily require skilled operators/developers so we could use some event-driven and functional programming concepts to control devices and interact with 3rd party systems.
The first tool we started to use to visualize and design the logic for workflow was Node-Red.
Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.
It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.
This tool can be installed in an Edge Computer/Server, which will be responsible for multiple deployments where the automation logic can be easily and quickly deployed remotely, which the need of updating software directly into the device itself.
A high-level architecture of this concept is presented in the diagram below:
From the diagram above, we can identify multiple components, which are interacting with each other using open-source technologies and industrial protocols like OPC-UA, Modbus, Profinet, etc.
- Edge Server: in this component, we are running services responsible for data storage, workflow orchestration, integration over 3rd party systems and cloud servers. In our Proof of Concept, we connected this server to the 5G network so we could communicate with devices over a wireless connection.
- Edge Gateway/Hardware: this component is also connected to the 5G network, for this demo we used a RaspberryPi board to act as a bridge device between Edge Server and devices. In this component, we have a basic service running to read/write data from RaspberryPi GPIOs to send and receive data to/from Edge Server over MQTT protocol.
- Computer Vision Module: this component is basically a camera connected to our edge hardware to enable object recognition tasks that will be published to the Edge Server and consumed by the workflow orchestration service.
With the current setup, we were able to achieve acceptable results with an average of 15ms network latency over our internal 5G network, which for our demo application is acceptable. This setup also supports a connection over an Ethernet Gigabit interface, if lower latency is required.
The next step for this project is to improve the implementation of device control on Edge Hardware to handle eventual connectivity issues and not rely 100% on Edge Server availability, considering a network failure might lead to hardware parts collisions and breaking mechanical parts.
