Edge processing refers to the execution of aggregation, data manipulation, bandwidth reduction and other logic directly on an IoT sensor or device. The idea is to put basic computation as close as possible to the physical system, making the IoT device as “smart” as possible.
Is this a way to take advantage of all of the spare computing power in the IoT device? Partially. The more work the device can do to prepare the data for the cloud, the less work the cloud needs to do. The device can convert its information into the natural format for the cloud server, and can implement the proper communication protocols. There is more, though.
Data Filter
Edge processing means not having to send everything to the cloud. An IoT device can deal with some activities itself. It can’t rely on a cloud server to implement a control algorithm that would need to survive an Internet connection failure. Consequently, it should not need to send to the cloud all of the raw data feeding that algorithm.
Let’s take a slightly contrived example. Do you need to be able to see the current draw of the compressor in your smart refrigerator on your cell phone? Probably not. You might want to know whether the compressor is running constantly – that would likely indicate that you left the door ajar. But really, you don’t even need to know that. Your refrigerator should recognize that the compressor is running constantly, and it should decide on its own that the door is ajar. You only need to know that final piece of information, the door is ajar, which is two steps removed from the raw input that produces it.
Privacy
This has privacy and information security implications. If you don’t send the information to the Internet, you don’t expose it. The more processing you can do on the device, the less you need to transmit on the Internet. That may not be a big distinction for a refrigerator, but it matters a lot when the device is a cell tower, a municipal water pumping station or an industrial process.
Bandwidth
Edge processing also has network bandwidth implications. If the device can perform some of the heavy lifting before it transmits its information it has the opportunity to reduce the amount of data it produces. That may be something simple, like applying a deadband to a value coming from an A/D converter, or something complex like performing motion detection on an image. In the case of the deadband, the device reduces bandwidth simply by not transmitting every little jitter from the A/D converter. In the case of the motion detection, the device can avoid sending the raw images to the cloud and instead just send an indication of whether motion was detected. Instead of requiring a broadband connection the device could use a cellular connection and never get close to its monthly data quota.
Data Protocol
There is just one thing to watch for. In our example of the motion detection, the device probably wants to send one image frame to the cloud when it detects motion. That cannot be represented as a simple number. Generally, the protocol being used to talk to the cloud server needs to be rich enough to accept the processed data the device wants to produce. That counts out most industrial protocols like Modbus, but fits most REST-based protocols as well as the higher level protocols like OPC UA and MQTT.
– Andrew Thomas, Skkynet
