If you’re an industrial manufacturer or OEM wishing to adopt IIoT as part of your overall digital strategy, you’ll find that edge computing is often a required component. Even though edge computing is used pervasively throughout IIoT, its exact purpose and place in the technology stack is not always clear.
This lack of clarification comes from the fact that edge computing doesn’t exist at a single spot in your architecture. Edge computing, which starts at the physical device and ends just before the cloud, represents a hierarchy of potential computing layers. Each layer filters, processes, and derives insights as data flows from the bottom of the hierarchy to the top.
Regardless of the number of layers in your hierarchy, they generally fall within three primary categories:
The primary purpose of an edge computing hierarchy is to exchange data fidelity for actionable insights. For example, an accelerometer will provide extremely high-frequency data, but that data is useless until it’s processed as vibration, downsampled, and ultimately fed to alerting systems much higher in the hierarchy.
The lowest layers in your hierarchy are often generating enormous amounts of raw data that are impossible or impractical to store in a data warehouse or send to the cloud. Each layer in your edge computing hierarchy will incrementally reduce data volume while simultaneously producing insights that are worth propagating to the next layer.
To help illustrate the concept of hierarchical edge computing, let’s look at an industrial equipment monitoring solution. These solutions are usually made up of hundreds of telemetry metrics per device, but to keep things simple, we’ll focus on tracing the path of vibration data as it traverses the hierarchy.
When monitoring industrial equipment, the embedded edge typically represents an existing controller, PLC, or retrofitted sensor.
Vibration data originates from an accelerometer, which is being sampled at hundreds or thousands of times per second. The controller, PLC, or sensor is performing a root mean square (RMS) algorithm to convert raw accelerometer data into a vibration frequency.
This is the first exchange of fidelity for insights. The raw accelerometer data never leaves the embedded edge. The vibration data is the insight that’s important. A controller or PLC might be using that insight as part of the machine’s operation. A retrofitted sensor won’t directly do anything with that data, since most sensors are designed to forward their data to the next layer in the hierarchy.
In industrial environments, the gateway edge is often the most important. It provides a way to extract valuable data from existing controllers while providing a secure connectivity bridge (i.e. gateway) between the actual equipment and the cloud.
The most common hardware we see at this layer in the hierarchy are industrial Linux gateways from vendors like Advantech, Dell, and others.
In our vibration data example, the purpose of the gateway edge is to periodically sample the vibration data that’s being created by the embedded edge. Without this edge computing layer, the data would be trapped in the controller or sensor and we’d be unable to use it for higher-level tasks like alerting and notifications.
At a minimum, this layer provides store and forward capability for the data being sampled. This is also a place where another round of processing can occur. For vibration data, it’s common to sample data on a fixed interval (e.g. one second) and then perform a smoothing algorithm. A smoothing algorithm, like a mean or medium, eliminates blips in the data. This prevents us from getting an alert if a technician simply bumps into a machine. We’d much rather get an alert if the machine’s vibration has been above a threshold for a certain amount of time, which is a much better indicator of a potential maintenance issue.
It’s the smoothed (averaged) vibration data that’s sent to the next layer in your hierarchy. If we’re sampling data at once per second and averaging over ten-second windows, we’ve essentially reduced the data volume by 10x between this layer and the next. That averaged data, however, is more useful and actionable than individual vibration samples.
For most IIoT solutions, it’s common for the network edge to be somewhat transparent. It’s often nothing more than an internet connection. For manufacturing environments, this is likely Ethernet or WiFi. For OEMs selling and monitoring fielded equipment, this could be a cellular connection. In these cases, the network edge still exists, but the hardware and processing that it does is outside the control of the solution itself. In this scenario, the edge hierarchy is essentially two layers deep.
An architecture we do see from time to time is the introduction of a network edge designed to consolidate data from multiple gateways to a single connection to the internet. This has the security benefit of reducing the number of devices connected to the internet, while also providing an additional layer of potential processing. In terms of the hardware for this layer, it’s usually very similar to the gateway edge and in some cases, can be thought of as another gateway edge layer.
In manufacturing environments, a network edge is a great place to implement alerting and notifications. In large environments, there could be dozens of gateways and a network edge allows us to consolidate that data to one spot. This provides a single, or relatively few, places where alerting is implemented, which makes development and maintenance much easier.
If your work order system (EAM, ERP, etc.) is hosted on-premises, then any automated work orders that may be generated must be done over your local network. The network edge, since it is still on your local network, is a great place to do this.
For our vibration example, the network edge layer is receiving averaged vibration data from the gateway edge layer. A single network edge device may be receiving data from hundreds or even thousands of machines. Since the data volume has already been reduced so drastically by the previous layers in the hierarchy, a single network edge device can handle the alerting logic for a huge number of devices.
Since this organization uses SAP, we’d like to submit a work order if the vibration for any individual machine exceeds a critical threshold. It can do so by directly checking the averaged data being received by the gateway edge or it can perform another round of processing if a more sophisticated algorithm is required.
Just like the gateway edge, a network edge is also a store and forward device. It may be directly forwarding data it receives or potentially doing some processing to reduce the data volume even more. This is the last stop before data is sent to the cloud for long-term storage, analysis, and visualization.
In our industrial equipment monitoring example, the network edge was implemented as essentially another gateway edge layer. There’s always a transparent network edge that is outside of your control. This is hardware and infrastructure required to provide you a connection to the internet, which is usually over Ethernet, WiFi, or cellular.
As it stands today, there isn’t an offering that combines connectivity and edge compute. There’s no way to introduce custom edge computing directly into that transparent network edge. There are programmable routers from companies like Cisco, which do technically provide this capability, but those are the domain of IT and the custom processing that is done is to facilitate network-level logic rather than application-level logic for a specific IoT solution.
5G and specifically Citizen Broadband Radio Service (CBRS) aim to deliver an entirely new option for connectivity with edge computing in mind. Right now, they’re calling it Multi-Access Edge Computing (MEC).
In many industrial environments, obtaining network access is a blocker for any IIoT implementation. Deploying traditional network technology like Ethernet or WiFi across potentially millions of square footage is not economically feasible. In comparison, relatively few cellular access points can bathe square miles in a private cellular network.
In this scenario, the network edge lives within the cellular access points. Since we’ve seen a lot of edge computing interest from operators like Verizon and infrastructure providers like Ericsson, we’ll see some compelling technology that truly combines connectivity and computing into a single offering.
The vibration example described in this article mentions several potential edge computing algorithms and alerting techniques. A question you may have at this point is, “How do I deploy and manage that logic?”
This is what IoT platforms like Losant are for. Losant provides capabilities for every level of the edge computing hierarchy. It provides the tools to develop, manage, and deploy logic across entire fleets of edge computing devices. Losant combines edge and cloud to deliver a complete IoT application enablement platform designed to quickly realize your IoT vision.
For telcos and mobile operators that want to offer compute-as-a-service for their own MEC solutions, consider partnering with Losant to provide our edge computing technology to your customer base. Talk to Losant’s Business Development team to learn how we can support your objectives.