Industry 4.0: IoT- and PC-based Control for the Use of Production and Machine Data

Machines, devices and facilities produce more data every day as they become more intelligent and connected. Machines and intelligent modules form the Internet of Things (IoT) as the basis for Industry 4.0 or Smart Industry. The potential of Smart Industry is in transforming this vast amount of data into valuable information, as well as business and competitive advantages. This promise can only be fulfilled if data is not only effectively reduced and analyzed, but also sensibly, promptly and securely transferred and communicated between the parties involved.

In order to enable the use of data for value-added services, ThingSpeak™ from MathWorks offers a secure data-exchange platform combined with the powerful data processing, analysis and visualization capabilities of MATLAB^® and additional toolboxes. PC-based control creates additional benefits by combining information technology (IT) and operational technologies (OT). Thanks to the use of standard IT concepts, networking and integration with other IT systems are quite simple.

Smart Industry and the automation pyramid

The Smart Industry will change familiar paradigms, such as the shape of the automation pyramid, which is now about a quarter of a century old. As a model for automation in factories, the automation pyramid can be understood in different ways. Among other things, it can be seen as a model for data exchange and processing in automated environments. This is what this article will discuss.

The automation pyramid consists of five layers, which are referred to as Layers 0 to 4. Functions of a similar nature, such as fieldbuses, PLCs, SCADA control systems, Manufacturing Execution Systems (MES) and Enterprise Resource Planning (ERP), are each uniquely assigned to a specific layer (Figure 1). The pyramid can be divided into two specific sections. The lower section includes the production process of sensors, actuators, drives, motors and tools in Layer 0, which do the actual work, and PLCs in Layer 1 which control the process. The upper section is the corporate management level, which consists of SCADA (Layer 2), MES (Layer 3) and the ERP system (Layer 4).

Production or M2M layer

The pyramid shape was chosen not only to represent the hierarchy, but also because information moves through the pyramid horizontally and vertically. Most of the data is generated below. The components in Layer 0 provide concrete real-time vertical communication between different parts of the machine and the control layer at sample rates in the range of up to several kHz, so fieldbuses have to transmit these enormous data streams. EtherCAT, Profinet and Ethernet/IP, among others, are generally used as buses here.

The PLCs in Layer 1 ensure that the planned process runs with the right steps at the right time and within the required tolerance limits. Horizontally, PLCs can communicate with one another either in real time (e. g. for the synchronization of motion profiles) via the EtherCAT Automation Protocol (EAP) or via UDP or in non-real time via OPC UA, ADS, TCP/IP and other protocols. Up to now, automation has mainly taken place in the two lower layers.

Company level: B2M

Business-to-machine communication (B2M) begins above the production layer. This communication usually does not take place in real time because it generally relies on switches, routers, firewalls, and other infrastructure devices that cause latency. Traditionally, decisions towards the top of the pyramid are made more slowly and are based on increasingly condensed data.

However, a current trend in the Smart Industry is the direct connection of the MES and even the ERP layer to PLCs. Unlike previous interpretations of the pyramid, these upper layers not only capture data from the layers directly below where it was reduced and analyzed, but can also send recipe data directly to PLCs and receive status reports in return. This enables the flexibility and response times required by the Smart Industry. Such a process can be implemented, for example, through Remote Procedure Calls (RPCs) and the TwinCAT 3 SOA-PLC (PLC for service-oriented architecture) from Beckhoff Automation.

Automation at the B2M layer

Future production and maintenance environments must include more and more facilities that are spread out across different locations or even worldwide. In the future, mechanical engineers would like to be able to compare and evaluate facilities operated worldwide and offer maintenance contracts based on remote functionality. Setting up automated processes at Layers 2 and 3 and linking remote facilities therefore make up the future of automation: These things make it possible to reduce expenditures, make more comprehensive data analysis and streamline and accelerate the execution of orders and business decisions across global organizations.

Both production companies and mechanical engineers must be able to do this not only efficiently, but also (as is often neglected in the discussion about the Smart Industry) securely, i. e. without endangering safe operation, network integrity and valuable confidential data.

SCADA as a point of entry

A good point of entry for engineers, production planners and mechanical engineers is the SCADA level (Layer 2), where all relevant production data arrives and is analyzed in a reduced form. An easy way to connect to external networks and get more computing power is to use an edge device. By adding this to the SCADA layer, companies can concentrate their MES and ERP work in fewer locations, or even a single location, where it is easy to give mechanical engineers access to data from the manufacturing and PLC levels, but not to business and enterprise data.

One approach to establishing secure connections between widely distributed factories is the use of VPNs. However, their setup and maintenance pose several challenges. Even connecting to and exchanging data with a single machine can be frustrating and affect operations.

An alternative is to use cloud-based solutions, which offer the advantages of secure data transmission (over a VPN) and minimize the disadvantages of maintaining the network connection. A common security mechanism is TLS (Transport Layer Security). This protocol is frequently used in cloud-based data communication. Traditionally, such solutions work on a client/server basis. When an engineer wants to communicate with a PLC at a remote location, the PLC that provides the data acts as a server, and the user's machine assumes the role of a client and establishes a direct connection to the PLC. This connection can easily be secured via TLS, but for such communication a port has to be opened in the firewall. Most IT administrators reject this, and the project is abandoned, leaving opportunities for data exchange and analysis untapped.

ThingSpeak as a secure publisher/subscriber platform with TLS v1.2

ThingSpeak uses a publisher/subscriber model to overcome these limitations and provide numerous additional benefits to the user (Figure 2). The ThingSpeak server itself can be placed in a secure network and may receive a static IP address. It then functions as a message broker so that all data made accessible to it is only sent via an outgoing connection. Each subscriber also sends its requests over an outgoing connection and receives data as a TCP response. This is very similar to how web browsers work and is therefore familiar to IT administrators.

This approach has a number of advantages. First, all parties involved in this communication only need to know the IP address of the message broker. Participants’ IP information must only be disclosed for the individual connection to the ThingSpeak server. New publishers and subscribers can easily be added. This makes the application flexible and scalable. Since each connection to the ThingSpeak server is essentially an outbound connection, this solution does not pose any additional firewall requirements. It can therefore be easily and securely integrated into existing IT infrastructures.

Channel configuration, data streaming and integrated MATLAB

ThingSpeak communication is based on channels that are easy to configure and only take a few minutes to use, even for new users. Channels have reading and writing API keys and can be set as public or private, with the default being private. Each channel contains 8 fields to store 8 data streams, e. g. sensor readings, electrical signals or temperatures. Each channel can be updated up to once per second. Each field of each channel has a standard visualization that automatically updates as new data arrives and includes iFrame code for easy embedding into other applications.

To collect data for these channels, ThingSpeak offers REST or MQTT APIs, the ThingSpeak™ Communication Library for Arduino and Particle devices, ThingSpeak Write-blocks in hardware support packages for Arduino and Raspberry, and other popular protocols. While the REST API is platform-specific, the MQTT API is general (Figure 3). The only requirement for MQTT is that the user specifies the correct user data format. This makes it easy to use for many applications and devices.

Once channel data arrives in ThingSpeak, it can be stored in the cloud or immediately processed and visualized. If the user is logged in with a MathWorks or ThingSpeak account, ThingSpeak provides the ability to run MATLAB code without an additional license. More than a dozen MATLAB toolboxes provide functions for statistics, analysis, signal processing, machine learning and more. For MATLAB scripts, execution can be scheduled at specific time intervals, allowing for updated calculations and visualizations at fixed times.

These scripts can be integrated into ThingSpeak by simply copying and pasting MATLAB code. For ease of use and testing, this code can be written on any MATLAB-licensed desktop or laptop PC. This makes ThingSpeak a natural cloud extension of the MATLAB desktop. Users can also configure messages to be sent to them via email or Twitter in the event of machine failures, parameter threshold overruns or other specific events so that they can respond instantly not only at the facility, but also from a remote location.

Back to the automation pyramid

Getting back to the automation pyramid: ThingSpeak alone does not guarantee a successful IoT environment, of course, but can easily be part of such an environment. To understand this, we need to take another look at how data collection and processing works in the pyramid.

In production, live data is processed locally on the controller in real time. This type of stream processing requires an enormous bandwidth and therefore fieldbuses with data rates of up to several Gbit/s. Beckhoff offers this using port multipliers with standard 100 Mbit/s EtherCAT or using EtherCAT G with a 1 Gbit/s data rate. The required algorithms can, for example, be developed in MATLAB and Simulink^® and then integrated into the PLC via MATLAB Coder™ and Simulink Coder™ together with the target for MATLAB/Simulink for seamless integration into the TwinCAT 3 automation software from Beckhoff: target for MATLAB/Simulink and target for MATLAB. This approach provides fast processing with deterministic response times and latencies of less than one millisecond, which is required for real-time controlled processes. Applications for this type of data processing are condition monitoring, energy monitoring, computer vision applications and information compression.

The disadvantages of restricting data processing to the PLC layer are that only a certain process can be monitored and controlled (without knowledge of adjacent processes, machines or facilities) and that only live data is used (no historical data).

Therefore, data coming from more than one controller is often processed on the SCADA layer. In Figure 4, this is implemented on the edge device – for example, an industrial PC (IPC) from Beckhoff – which forms the connection with ThingSpeak™. This structure allows data stream processing and comparison with stored data. It differs significantly from the PLC layer, on which only data streams flow and practically no storage takes place.

An advantage of data processing on an edge device is the high computing power and the extensive working memory in combination with the high bandwidth of the Gbit-LAN. However, it cannot achieve deterministic response times and therefore cannot be used to control processes in real time. Here, too, the required code can be written in MATLAB or generated from Simulink models. Deployment on the edge device, e. g. via MATLAB Compiler™, ensures fast execution of runtime applications (Figure 4). With the TwinCAT 3 interface for MATLAB/Simulink, fast communication between the PLC layer and the MATLAB runtime can be achieved on an edge device that includes client and server functionality. The latter includes the possibility of displaying functions written in MATLAB as callable functions from the PLC (asynchronous remote procedure call). Typical applications include cross-process statistics, model-based optimization, anomaly detection and information compression.

The entire data processing procedure described so far takes place locally in a single, closed network. While this approach can provide a comprehensive overview of a facility or site, it does not enable monitoring or control of processes that are distributed across multiple sites. ThingSpeak offers this capability.

Outside the conventional pyramid

Since ThingSpeak is connected to the edge device via an external network, data reduction is often required for bandwidth reasons. This reduction can be achieved, for example, by algorithms that can be easily integrated into the runtime application created by MATLAB Compiler. ThingSpeak can store the incoming data stream or process it immediately. Information reduction can also be performed within the PLC with integrated MATLAB^® functions, and a direct connection from the PLC to ThingSpeak can be established. Due to latencies and bandwidth limitations, ThingSpeak cannot offer deterministic response times and therefore cannot offer real-time control.

However, the advantages are tremendous. First, the integration of different processes is simple. All the user has to do is specify the appropriate channels and start collecting data. In this way, any number of facilities can be connected to ThingSpeak. Second, the storage capacity is much larger, so historical data can be stored to aid maintenance and business decisions over long periods of time. This is interesting not only for manufacturing industries, but also for plant manufacturers, which can now monitor machines sold to customers around the world, offer maintenance contracts and compare performance according to environmental conditions, all from a single location. (Figure 5).

ThingSpeak also offers a serverless architecture. Of course, the ThingSpeak cloud contains servers, but they work without users having to maintain or update them.

As mentioned earlier, ThingSpeak offers integrated MATLAB^® functionality and multiple toolboxes. This allows users to use a wide range of computing, analysis, statistics, control and visualization functions to create comprehensive, global analyses of their company, machine maintenance or scientific projects.

The use of MATLAB in turn enables them to extend their ThingSpeak activities to the desktop to develop algorithms and code or provide real-time and runtime applications. This makes ThingSpeak an effective link between a comprehensive modeling and design platform on the one hand and real industrial and scientific applications on the other. In addition, companies can use ThingSpeak functionality for business applications.

Summary

The traditional automation pyramid must be intensively adapted to meet the requirements of the Smart Industry. In particular, it must be opened to external networks in order to be able to provide automation for the B2M layer and to allow its components to exchange data and receive updated algorithms or production orders in more flexible ways.

ThingSpeak in the cloud is a natural extension of the MATLAB^® desktop and connects it to environments that can be represented by the automation pyramid. The solution can be used to collect, monitor, process and utilize data generated in different environments from industry to science, as well as interact with machines at all levels down to individual sensors or actuators.

In manufacturing companies, data can be analyzed on the SCADA/MES/ERP layer and then immediately used via messaging, and algorithms or applications can be downloaded to production environments. Because ThingSpeak is a cloud service, users can easily connect to ThingSpeak™ simply by using secure outbound TLS v1.2 connections without having to maintain servers.

Beckhoff offers industry-proven, scalable hardware with CPU performance that is suitable for data processing directly in production and at the edge, as well as the real-time-capable software TwinCAT 3, which enables OT tasks such as motion control. TwinCAT 3 includes easy-to-use integration products for MATLAB, Simulink and other software solutions. Examples include ADS-server and ADS-client functionality for MATLAB Compilers, the direct integration of MATLAB^® and Simulink^® into TwinCAT real-time software, and the connection to ThingSpeak™

ThingSpeak provides critical, flexible functions for the Smart Industry and the Internet of Things. Based on data-rate, data-compression and computing-power requirements, ThingSpeak can either serve as a processing and visualization platform with integrated notifications or be used to deliver pre-processed data to the MATLAB desktop or download control, monitoring and optimization applications to remote edge devices and PLCs.

The learning curve for ThingSpeak consists of very small, effective steps. The initial steps only take a few minutes and encourage users to start with simple tasks, but quickly extend their knowledge to useful applications with real added value.

Beckhoff^®, TwinCAT^®, EtherCAT^®, EtherCAT P^®, Safety over EtherCAT^®, TwinSAFE^®, XFC^® und XTS^® are registered trademarks of Beckhoff Automation GmbH and are licensed from Beckhoff. Other references used in this publication may be trademarks the use of which by third parties for their own purposes may infringe the rights of the trademark owners.