Data is vitally important for businesses today, supporting decisions ranging from optimizing production in real time to predicting (and avoiding) equipment failure. Many companies gather and analyze this data through IoT deployments that consist of sensors and gateway devices—the sensors take in data and send it to the onsite gateway device, which then processes and performs initial analysis, and, in turn, sends the relevant data on to the cloud.
Traditionally, IoT deployments rely on embedded computing architectures, which means that the software is tightly integrated with the hardware it runs on. The problem with this situation is that making any changes to the software can be difficult because of how intertwined it is with the underlying hardware. Updating, adding, or deleting applications is therefore not easy, and often requires you to physically access the gateway in question. For IoT deployments in remote areas—wind turbines, oil rigs, etc.—each in-person visit can be enormously expensive.
Faced with the need to update their gateway software, most businesses instead typically decide to “rip and replace” the entire system, removing their old gateway device and installing a new piece of hardware with the latest applications included. However, as soon as changes need to be made to this new software, the cycle repeats itself. It’s an inefficient, expensive, and wasteful approach to IoT, but for a long time, it’s been the only viable option.
Now, modern technologies like virtualization are being applied to edge devices and are disrupting the status quo of embedded computing. By virtualizing the underlying hardware of edge gateways, it’s easy to add, remove, or update the applications on the device because they are no longer tied directly to the hardware.
An additional benefit of virtualization is that it allows applications on the same device to run in complete isolation from each other, which makes it easier to host multiple applications on one gateway. If a business needs to add or change the software on their gateway, they no longer have to buy a whole new device to accomplish that task, or even visit the site at all, saving time and money.
What’s interesting about the old “rip and replace” methodology is that it was necessitated by the embedded application architecture, rather than actual physical device limitations. In other words, edge gateways have long had the capacity to run multiple applications simultaneously and to reconfigure them if needed—they simply haven’t had the software architecture in place to do so. To use an analogy from chemistry: the hardware isn’t the rate-limiting factor.
You may wonder: in what circumstances would a business want to adjust the applications running on their edge gateways? There are actually many use cases for making changes. For instance, Zededa works with a large wind farm operator in North America. Currently, this
Shiv has over 8 years experience working on Internet of Things and an avid user of Drones