In industrial environments, IoT-enabled devices are being used more and more often. Usually, the data from these devices is processed in the Cloud. Scalability is a major advantage of cloud computing. The required resources can be automatically adapted to the demand. In addition, any computer can access the data in the Cloud. Perfect conditions for using the Cloud in combination with IoT devices. However, this requires a fast and stable Internet connection that provides an adequate bandwidth. In everyday business, such connections are not always available. In addition, the Internet costs also play a role, especially if the connection is made via mobile communications and the corresponding volume tariffs. With conventional IoT applications, this is not a major problem, since often only small, clearly structured data packets are transmitted. And since the devices are potentially distributed across the globe, the network load can also be distributed and balanced. In the Industrial IoT, it's a different story: Data typically accrues at one or more hot spots. So, for example, at a machine or plant. As soon as sensors with high data rates, such as cameras, are used, the available bandwidth is often no longer sufficient to send all the data to the Cloud. In addition, the resulting Internet costs can get so high that the whole IIoT scenario becomes unprofitable.
Edge computing serves as a kind of intermediate layer between the Cloud and the IoT devices. The data is now no longer processed only at a central location, but also decentrally, directly at the point of origin. Afterwards, only the really relevant data is sent to the Cloud. This cuts down on bandwidth and enables periods of offline operation. The central collection and pre-processing of data directly at the point of generation results in further clear advantages:
Security is significantly increased
Only a punctual internet connection is needed for the transmission of the results and not a permanent online status. The data can be anonymized on site. Data that is not wanted to be revealed to the Cloud can be removed.
The system is fast
Latency (the runtime of a signal within a system) is reduced because data does not have to be sent to the Cloud for further processing. Decisions made by the edge system and not by the controller are fast enough.
Gateway Functionality
Often, in industrial environments, no Internet-capable sensors and actuators are used. Instead, the field level is accessed via a PLC. Sensor data can be published by the controllers via OPC UA or Modbus. Here, an Edge Gateway steps in collecting the exported data and making it available to the Cloud. From a functional point of view, there is only a slight difference to the IoT gateway. However, the use of an Edge architecture for the IoT gateway makes the difference and offers many possibilities to use the potential of Edge concepts.
Reduction of Data Volume/Data Security, Data Protection and Data Sovereignty
The collected data can be aggregated and analyzed before it is sent to the Cloud. Unimportant data can be removed by filter modules. As a result, not all data is sent to the Cloud anymore, but only selected data series and analysis results. Data reduction is correspondingly relevant when it comes to the issue of security and data protection. With Edge Computing, for example, anonymization can be carried out directly where the data originates. Data sovereignty can thus be clearly defined and controlled. Companies can decide which data they want to share and which they do not.
Local Response to Events
Example: When limit values are exceeded, user-defined actions are to be executed based on the collected data. Therefore, the Edge device needs to be equipped with a rule engine. These actions must also be executed when there is no connection to the Cloud. This raises the intriguing question of where the line is drawn between the responsibility of the controller and the Edge device. Simple and/or little data could potentially be handled more easily in the PLC. That's why local response to events in the Edge Device still plays a less important role in practice.
Real-time Data Analytics and Machine Learning
But Edge Gateways don't just deliver data to the Cloud. Equipped with appropriate additional software, they can already add value on site or make a valuable contribution to the overall solution. A frequently discussed scenario is that insights are already gained "on the Edge". This is particularly interesting in the machine learning environment. It is the idea that a neural network is trained in the Cloud with the data from the OT. Once the training is completed, the neural network can be packed, and its essentials extracted to the Edge.
Local Storage of Large Data Volumes
The local execution of Edge applications enables an interaction with local systems. Images or measurement series that are generated as part of quality management and have to be archived for traceability can thus also be stored on a local server by the Edge device, for example.
Cloud-Managed On-Premises Applications
Another use case is an on-premises application managed by the Cloud. Here, for example, analysis software and configuration data for various locations are to be uploaded from the Cloud to the Edge devices. The actual execution and data processing, however, then takes place locally and completely independently from the Cloud. Adjustments can thus be made centrally in one place - in the Cloud. The changes are then applied to all affected systems. Updates, for example, can be imported without the need for a service technician to be on site.
Edge Without the Cloud
The software technologies generally used for Edge are not only suitable for use cases involving the Cloud. It has proven quite successful to implement OT near applications by means of Edge technology, for which a Windows computer was previously intended. Examples are tools for supporting commissioning and/or maintenance as well as on-site diagnostics.
The success of an Edge solution depends on its integration into a suitable cloud platform. Especially with larger numbers of devices, it is no longer sufficient to just send the measurement data to the Cloud. An additional solution is needed to efficiently manage the devices and the software running on them. The good news is that if the appropriate framework of the Cloud providers is used, these services can be used without much effort. They enable secure provisioning of new devices, management of existing devices, and management of the software running on the Edge devices. The bad news: In practice, the frameworks of the various providers are not compatible with each other. MQTT has become the standard protocol for data transport, but the message format used and the protocols for device management are not standardized. A pragmatic approach is to commit completely to one provider. For those who don't want to do that, hybrid solutions are interesting. Here, the Edge devices are still managed by a fixed platform - but the cloud-specific connection can be integrated and executed on the Edge device. In this way, the data can also be sent to the corresponding target cloud.
The hardware requirements for Edge Gateways are strongly dependent on the respective use case. The central question is: Is the Edge solution primarily required to transfer device data from the field level securely and efficiently to the Cloud or should a comprehensive analysis of the data already be carried out? In practice, a Linux-based PLC is often used for communication with the field level. Its connectivity to the bus systems makes it particularly well suited for this purpose. Supplemented by the Edge functionality, it can be used directly as a so-called Edge Controller to forward data from the field level to the Cloud. This is a good solution if further data processing is not required. For more ambitious projects, the performance of Edge Controllers is quickly reached. In case applications like machine learning have to be carried out, a more powerful device is needed. This task can be performed by an appropriately equipped Edge Gateway. However, a PLC can still be used for the connection to the field level. As a subordinate device, it supplies the data to the Edge Gateway. OPC UA is a suitable standardized protocol for this purpose. The big advantage: the Edge Gateway itself no longer needs to have special connections for linking the field level. Accordingly, servers or virtual machines can also be used. But in general, hardware is becoming increasingly irrelevant in Edge Computing. Virtual machines in combination with IO gateways are now part of the standard repertoire.
The IoT approach of implementing as much functionality as possible in the Cloud often fails in the industrial environment due to the volume of data to be transported and limited connectivity. This is where solutions 'on the Edge' come into play. They are close to the point of origin of the data and allow early interventions, initial analyses or applications, which so far have only been typical for the Cloud. By linking cloud-based applications with Edge applications, coherent overall solutions can be created in the industrial environment. At the same time, it is becoming apparent that Edge technology is being used to build applications that are close to OT without any reference to the Cloud. Currently, various competing proprietary approaches dominate. As often happens in automation, there is hope that increasing standardization will further reduce barriers to entry and that additional added value can be generated through cross-vendor collaboration. Here, for example, the concepts of the Open Industry 4.0 Alliance provide a promising approach. Especially for the collection of data from the OT, there is a guideline in form of Open Edge Computing based on OPC UA, which is widely used in the OT, and which considers the concepts of digital twins in the form of an AAS.
If you are interested in learning more about the possible applications as well as the strengths and weaknesses of Edge Computing, please do not hesitate to contact our team of experts.