Both edge computing - also known as fog computing - and cloud computing are about creating a cyber-physical system by networking mechanics, machine control and software systems in order to be able to reuse data or information. Examples of applications include condition monitoring or new pay-per-use models. The difference? Edge computing often takes place within a company's own network. Data is pre-aggregated here in order to reduce the amount of data for cloud communication or to run algorithms, data evaluation and analyses locally. Cloud computing also offers global access to data and analyses and enables extended functions, such as the global comparison of plant productivity. Both methods can be used in isolation, but smart solutions generally use both methods in combination.

Which option is the right one depends on many factors. Not least the extent to which the machine operator is prepared to entrust their data to a cloud. Before taking the first steps towards implementation, machine manufacturers should therefore ask themselves a few questions: What services do I want to offer? Quick help with problems through simple remote access? Or condition monitoring and predictive maintenance for needs-based maintenance and secure spare parts business? With an AI-supported cloud solution? Or would you prefer a local solution? And what about security?

Standards help

Once the answers to these questions have been found, it is important to clarify which access options exist and which data is required in which quality and frequency in order to generate valuable information for the digital services. There are also a few things to consider when it comes to the actual implementation.
A future-proof solution should be able to 'grow', i.e. be open to expansions that meet the constantly increasing demands of the market. As a rule, this can only be achieved by using open standards.

OPC UA is already established as a communication standard for control systems, as almost all common control systems support the platform-independent, service-oriented architecture and enable OPC UA-standardized data models for mechanical engineering. If, on the other hand, the data is located on an edge computer and needs to be distributed from there, MQTT (Message Queuing Telemetry Transport) is often used. A lean solution with little overhead that does not unnecessarily increase the amount of data to be transferred. The extension to a cloud solution is easy, as MQTT connections are now standard with almost all cloud providers, including Lenze.
Secondly, it is about distributing the software, because regardless of whether it is on the edge computer or in the cloud, it should be adaptable without additional effort. Containerization using Docker has proven itself many times over here. The software runs in this container with all the necessary dependencies, libraries, etc. It also docks onto the operating system in a lean manner and is supported by common operating systems. Docker containers can be easily updated and offer options for high security.

More flexibility

Schematic representation of a cloud and edge computing architecture for industry.

© Lenze

This brings us to the next key point - flexibility. If I use a modular and flexible architecture, have easy access to my data and the option of using software anywhere, I can start with a quick and small solution. The first step is to retrieve the data from the controller or field device and run the software or container on a local edge computer. A connection to the cloud is not absolutely necessary. However, if my machines are to be networked worldwide and processes optimized globally, the solution must inevitably be expanded. The same software architecture is reused and the data is sent to a cloud of my choice using MQTT. The user will not notice the difference. This simple approach shows the added value and will lower the inhibition threshold for the use of cloud solutions.

From the field

The first projects are already being implemented - as is so often the case with innovations, the automotive sector is at the forefront here too. In one specific application example, data from around 1000 drives distributed across several systems is being used. The first step in the project was to enable pure data access in order to compare the drive data from the systems and identify deviations. The recorded data is stored locally and used to gain initial experience in handling, processing and analyzing the information. Only in the second step will the focus be on condition monitoring and
predictive maintenance.
The first step was to decide which hardware, software and network architecture would be required to cyclically read, process and store parameter data from 1000 drives. The choice fell on a decentralized architecture that divides the 1000 drives into around ten edge computers. The individual edge computers connect to the drives via Profinet and read the drive data cyclically and event-controlled.

Example of communication using the MQTT standard. An MQTT client is used on the edge computers, which sends the parameters as MQTT messages to an MQTT broker on the database server.

© Lenze

Next, the communication between the individual edge computers and the database server is defined. In this project, MQTT is the chosen communication standard, as this protocol has a lower overhead, publish & subscribe mechanisms, the MQTT brokers can connect to thousands of publishers and subscribers and can process millions of encrypted messages in a very short time.
An MQTT client is used on the edge computers, which sends the drive parameters as MQTT messages to an MQTT broker on the database server. A so-called 'time series database' is used, which is specially specialized for this type of information - namely cyclical data with a time stamp. It offers clear storage and performance advantages over relational databases without having to forego an SQL-like syntax for data queries. Another system requirement was to automatically compress older data so as not to exceed the available memory limits. Other applications that search for changes in certain parameter data and send notifications, for example, can be easily integrated.

The information and system behaviour are visualized via system or data dashboards. These are based on the user's requirements - the commissioning engineer and maintenance staff need dashboards that allow them to assess the current status of the installed system: Are all drives connected and sending data? Is the data consistent? Are there any error entries? Are there enough resources? As well as many other details. You also want to monitor and evaluate the drive data: Are all motor temperatures within the limit values? Have torques, motor current consumption or overrun changed over time? And much more.

Cloud or edge computing?

Klaas Nebuhr is Chief Marketing Officer at Lenze Digital.

© Lenze

Industry 4.0 projects, and specifically 'condition monitoring' and 'predictive maintenance', always start with data acquisition, data transmission, data storage and data monitoring. Special algorithms can then be implemented that automatically analyze the behaviour of the machine processes and provide timely information in the event of changes that could lead to a fault.
Whether cloud or edge computing is the right choice depends on the user's specific requirements. Experts help users to choose the right technology and provide support in the development of machine learning and AI algorithms. Together with the machine manufacturer's knowledge, this results in new solutions and services that generate economic benefits from the digital transformation.