IoT Edge Computing — Why?
Let’s sojourn into Edge Computing topic. This will be an introduction to what it is and why you should care. We’ll get into more detailed examples later on.
This is always a good question to start with, otherwise, you have TPS reports to fill out. Thinking back to the 90s or even 80s, you’d have all these sensors and other devices installed in your business to monitor things or automate things. Back then, we called them embedded devices, IoT wasn’t a thing yet — not that anyone’s bitter about that.
So you’d have these embedded devices and they’d upload their information to some server running in that one closet that’s under lock and key. The closet would have a few servers, maybe in a rack, but more likely on the floor in a pile. If you were lucky, the data went into some kind of database that a couple of people knew how to restart when you didn’t get that end-of-the-week report. If you were a bit luckier, you might have had them going into an AccessDB with some kind of Windows application (written in VB6 of course) that let you see dials and presets and flow information.
Fast forward to today and we have this fancy Cloud thing. Instead of embedded devices with AccessDB and VB6 Windows programs, we have IoT and mobile apps and smart dashboards and predictive maintenance. All of this data is being generated and sent up into the Cloud so you can do all manner of fancy things. Except there is a bit of a problem because sensors don’t always transmit the data. Also, how do you handle security for a few hundred devices in your factory when your IT team is a few folks working out of Chicago? Or was it Minneapolis? Then someone wants to run some kind of AI on this data and generate automated alerts or even manage manufacturing equipment from the Cloud.
Now your data acquisition and processing are separated by hundreds of miles. Also, what happens if the Internet connection to your factory gets interrupted for some reason? Cloud is useless at that point and that AccessDB is starting to look better and better. I know, I can’t believe I typed that either.
At this point, I’m going to ask you for a favor — step away from AccessDB please — no, your enterprise DB2 with that mainframe in the basement is not the answer either. Instead, let’s talk about edge computing.
Simple version, it’s a computer that resides close to your sensors, collects data, and can do data processing. This way, instead of you shipping all that data to the Cloud or to your data center, you deal with it locally first.
Think of it this way, you want to do your processing as close to data acquisition as possible. This helps you save money on bandwidth costs. If you can clean up the data before uploading it, then you save on storage costs as well, since you don’t need 100% of the video from your security systems, right?
Another benefit to think about: if your network goes down, the edge device(s) can store the data until network connectivity is restored and upload it at that point.
Let’s run through a couple of small examples to get a general idea.
You’re in charge of the PCB assembly plant. After the various components are placed onto each PCB, the PCBs enter a reflow oven. You have to carefully monitor the temperature of the oven to make sure the solder melts but the temperature doesn’t get so hot as to damage the components. There’s a report generated for every batch run through the oven that the customer gets. That’s how you can certify that the manufacturing process is not causing defects.
There’s a power surge in the building and it damages the network router, cutting your Internet connectivity. The oven sensors cannot upload the data without Internet connectivity, so you cannot generate the report for the customer.
One way to solve this is to use an edge device. The sensors submit their data to this device and the device manages uploading the data to your data center. If there is no Internet connectivity, you can generate a report from the readings stored on the edge device.
You’re heading up a new mining project. This means there’s a mountain of equipment distributed over many square miles. You’re lucky though, cause it’s all new equipment that has all manner of fancy sensors.
You’re not so lucky because half of the equipment is constantly moving around and it’s impossible to get good wireless coverage everywhere. So you decide to deploy a mesh network solution with many access points. Problem is, connectivity is spotty. The wireless network vendor you went with doesn’t have great support for mesh networking or client hand-off. Also, having giant metal things moving around tend to block wireless signals.
In a stroke of brilliance, you decide to add edge compute devices to each of the access points. This allows you to always record the data from the sensors locally and when connectivity is re-established to transmit this data upstream.
Hopefully, you’re convinced that edge computing can improve your IoT projects. How do you go about buying a solution though?
As always, it depends. Are you just doing store-and-forward of the data or do you need complex computing needs? The difference can be a $30 Raspberry Pi or a rack full of GPUs that’s > $10,000 a piece.
Here’s another issue to worry about, it’s another device to monitor and manage. What happens if it fails? Do you need a backup? How do sensors handle fail-over scenarios when one of the edge devices fails?
Edge computing is not a silver bullet, rather it’s another arrow in your quiver when looking to address a set of issues inherent in any IoT project. These include (but are not limited to) connectivity, bandwidth management, sparse/bad data, heavy computing needs, etc.
As always, start small, run a couple of experiments with cheap hardware and see what you can learn.
IoT Edge Computing — Why?
Research & References of IoT Edge Computing — Why?|A&C Accounting And Tax Services
Source
0 Comments