Machines, devices and plants produce more and more data as they become smarter and more networked. Smart industry promises to turn these huge amounts of data into valuable information. Beckhoff and Mathworks show how this challenge can be tackled.
Smart industry will transform familiar paradigms, such as the shape of the automation pyramid, which is now about a quarter-century old. As a model for automation in factories, the pyramid can be understood in several different ways. One of them is how data is exchanged and processed in automated environments.
The automation pyramid comprises five layers, which can be divided into two sections. In the bottom section, we find the production process with sensors, actuators, drives, motors and tools in layer 0 doing the actual work and PLCs in layer 1 controlling the process. The top section forms the business management level, made up of Scada (layer 2), MES (layer 3) and the ERP system (layer 4).
From shop floor to business level
The pyramidal shape was chosen not only for hierarchical reasons but also because information travels horizontally and vertically. At the bottom, the amount of data produced is highest. The components in layer 0 communicate vertically in hard real time from different parts of the machine with the control layer at sample rates of up to some kilohertz, requiring field buses to transfer these enormous data streams. The buses used here include Ethercat, Profinet and Ethernet/IP.
The PLCs situated on layer 1 make sure that the intended process is executed with the right steps at the right time within the tolerances required. Horizontally, the controllers may communicate with each other either in real time, using Ethercat Automation Protocol (EAP) or UDP, or in non-real time, employing OPC-UA, ADS, TCP/IP and other protocols.
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Moving up from the shop floor, business-to-machine communication starts. This communication usually isn’t real-time, since it typically relies on switches, routers, firewalls and other infrastructure devices that cause latencies. Traditionally, decisions are made more slowly toward the top of the pyramid and are based on increasingly condensed data.
A current trend in smart industry is to directly connect the MES and even the ERP to PLCs. These top layers now not only acquire data from the layers directly below them, where it has been reduced and analyzed, but may also send recipe data directly to PLCs and get status reports in return, paving the way for the flexibility and response times smart industry will require.
Taking automation to the business level
Future production and maintenance environments will have to cope with more and more plants being distributed across different sites, and machine builders will want to assess equipment running worldwide and offer maintenance contracts based on remote functionality. Establishing automated processes in layers 2 and 3 and interconnecting remote plants is therefore the future of automation. Production businesses and machine builders need to be able to do this efficiently and securely, ie without jeopardizing safe operation, network integrity and valuable confidential data.
A good entry point for engineers, production planning and machine builders is the Scada level (layer 2), where all the relevant production data arrives already reduced and is subsequently analyzed. A simple way to connect to external networks, and to add computing power, is to insert an edge device. By doing this at the Scada level, businesses will be able to concentrate their MES and ERP efforts at fewer sites or even a single site, where it’s easy to grant machine builders access to data from the shop floor and PLC levels but not to business and company data.
One approach to establishing secure connections between distributed factories is to employ VPNs, but setting up and maintaining them comes with several challenges. An alternative is to rely on cloud-based solutions that offer the advantages of secure data transport (like VPN) and minimize the disadvantages when it comes to maintaining the network connection.
Introducing Thingspeak
Cloud-based data communication often uses transport layer security (TLS). Traditionally, solutions of this kind work on a client/server basis. If an engineer wants to communicate with a PLC at a remote site, the PLC offering the data acts as the server and the user’s machine takes the role of a client, establishing a direct connection with the PLC. Securing this connection using TLS is no problem, but a port would need to be opened in the firewall for this kind of communication, which most IT admins will simply refuse.
The Thingspeak platform from Mathworks uses a publisher/subscriber model to eliminate these limitations while offering additional benefits to the user. The Thingspeak server can be placed in a secure network and act as a message broker so that any data published to it is sent through an outgoing connection only. Any subscriber will send its requests through an outgoing connection too, receiving data as a TCP reply (like a web browser).
This approach has advantages. Any parties to this communication only need to know the IP address of the message broker. There’s no need to disclose IP information of participants beyond the individual connection to the Thingspeak server. Adding new publishers and subscribers is straightforward, making the application flexible and scalable. Because any connection to the server is essentially an outgoing one, there are no additional firewall requirements, making it easy to integrate with existing IT infrastructures while at the same time keeping them secure.
Using Thingspeak
Thingspeak communication is based on easily configurable channels. These have read/write API keys and can be made public or private. Each channel contains eight fields to store eight streams of data, such as sensor readings, electrical signals or temperatures. The maximum update rate is once per second. Each field of each channel is provided with a default visualization that updates automatically as new data arrives.
To acquire data for these channels, Thingspeak offers Rest and MQTT APIs and specific hardware support. While the Rest API is platform specific, the MQTT API is general. MQTT’s only prerequisite is that the user specifies the correct payload format, making it easy to deploy for numerous applications and devices.
Once channel data is in Thingspeak, it can be stored in the cloud or immediately processed and visualized. The platform includes the ability to run Matlab code without the need for any further license. More than a dozen Matlab toolboxes provide functionality for statistics, analysis, signal processing, machine learning and more. Matlab scripts can be scheduled to run, enabling updated calculations and visualizations at fixed times.
Scripts can be inserted into Thingspeak by a simple copy-and-paste of Matlab code, which can – for ease of use, as well as for testing – be written on any desktop or laptop PC with a Matlab license. So Thingspeak becomes a natural cloud extension of the Matlab desktop.
The pyramid revisited
Thingspeak alone of course doesn’t guarantee a successful IoT environment, but it fits into one quite straightforwardly. To understand this, we need to take another look at data acquisition and processing in the pyramid.
On the factory floor, live data is processed locally on the controller in real time. This requires enormous bandwidth and therefore field buses with data rates of up to some gigabits per second, which Beckhoff offers by using port multipliers with standard 100 Mb/s Ethercat or by using Ethercat G with a 1 Gb/s data rate. The algorithms required can, for example, be developed in Matlab and Simulink and then integrated on the PLC using Matlab Coder and Simulink Coder, together with the target for Matlab/Simulink for seamless integration into the automation software Twincat 3 from Beckhoff. This approach guarantees fast processing with deterministic response times and latencies in the range of sub-milliseconds required for real-time controlled processes. Applications for this kind of data processing are state monitoring, energy monitoring, vision applications and information compression.
The disadvantages of confining data processing to the PLC layer are that only one specific process can be monitored and controlled (without knowledge of adjacent processes, machines or equipment) and that only live data is used (no data histories). For this reason, data provided by more than one controller is often further processed at the Scada layer. This can be implemented on an edge device – for example, an industrial PC – that forms the link to Thingspeak. Such a structure enables stream processing, as well as comparison with stored data, which is quite different from the PLC layer, where data just streams along with virtually no storage.
Data processing on an edge device can combine high computing power and memory with high-bandwidth Gigabit LAN. However, it cannot produce deterministic response times and therefore cannot serve to control processes in real time. Again, the required code can be written in Matlab or generated from Simulink models. Deployment on the edge device (with Matlab Compiler) guarantees fast execution of runtime applications. Using the Twincat 3 interface for Matlab/Simulink, fast communication can be established between the PLC layer and the Matlab Runtime on an edge device. The latter includes the possibility to represent functions written in Matlab as a callable function out of the PLC. Typical applications are cross-process statistics, model-based optimization, anomaly detection and again information compression.
All data processing described up to this point takes place locally in one closed network. Although this approach can give a comprehensive overview of one plant or site, it doesn’t allow for monitoring or control of processes distributed across various locations. This is a capability offered by Thingspeak.
Outside the traditional pyramid
Because Thingspeak is connected to the edge device through an external network, data reduction is often necessary for bandwidth reasons. This reduction can be performed by algorithms readily integrated into the runtime application created by Matlab Compiler. Thingspeak can store or immediately process the incoming data stream. Information reduction can also be performed inside the PLC with integrated Matlab functionalities and a direct connection from the PLC to Thingspeak can be established. Due to latencies, as well as bandwidth limits, Thingspeak cannot provide deterministic response times and real-time control.
Nonetheless, the benefits are huge. Integrating different processes is easy. The user only needs to specify the corresponding channels to start collecting data. This way, an arbitrary number of facilities can be connected to Thingspeak. Additionally, the storage capacity is much higher, allowing data histories to be saved to support maintenance and business decisions over long periods. This is interesting not only for production industries but also for equipment manufacturers, who can now monitor machines across the globe, offer maintenance contracts and compare performance based on environmental conditions, all from a single location.
Thingspeak also provides a serverless architecture. Though the Thingspeak cloud includes servers, they operate without any need for users to maintain or update them. The platform also comes with integrated Matlab and several toolboxes. The use of Matlab, in turn, enables users to extend their activities in Thingspeak to the desktop for algorithm and code development or deployment of real-time and runtime applications. This makes Thingspeak an effective link between a comprehensive modeling and design platform and industrial and scientific field applications, while at the same time enabling companies to leverage its capabilities for business uses.