Three Distinct IoT Edge Computing Patterns You Need To Understand

The Internet of Things (IoT) is rapidly becoming a reality in many industries, and it’s increasingly evident to most folks that two things are essential for commercial success:

• The data generated by a physical web of machines and processes (obvious)
• Machine learning on that data (not as obvious)

While machines generate a lot of data, it tends to be highly repetitive and noisy. Any given bit of that data is in fact unlikely to convey valuable information by itself. While it’s clear you need that physical web data, without analytics you cannot create the actionable insight that drives the value that justifies IoT investment.

Getting Compute and Data Together – Where, When, and How

Analyzing data obviously requires compute resources that can process that data. If the compute capacity for IoT resides in the cloud, complex effort and expense are needed to bring that data to the compute, which also inevitably delays the availability of that data for processing. Most IoT platforms you run into today work this way, which limits their potential.

Each IoT scenario has its unique constraints, of course. In some cases, connectivity is expensive. In others, its capacity is restricted or inconsistently available. Many machines have highly specialized requirements for interacting safely with them. There are even cases where you have no choice but to bring the compute capacity to the data source instead. At least for now, it’s hard to argue that it makes sense for an offshore oil rig generating 1-2 terabytes daily to immediately send all that raw data up to the cloud without at least analyzing it onsite for potential value first.

There are other considerations as well. What if the actionable insight you’re able to create is highly time sensitive? What if you want to archive historical data in the cloud to train machine learning? What about the data needed to drive useful apps that are not allowed to access the machines that generate it?

Three Distinct IoT Edge Computing Patterns

There are three patterns you consistently run into as you get near a physical web data source. All of them address legitimate concerns, affect different audiences, and require specialized approaches. There’s a distinct cloud role for each of them as well. Let’s break this down by presenting each category of problem and how solutions are likely to be architected to address them.

The Cloud Edge Pattern – High Capacity Computing and Analytics with Near-real-time Cloud Support

A “Cloud-Edge Node” is basically a rack-size machine that could be located near the edge of the network (such as in an industrial building or by a wind farm) if it’s connected by high-quality cloud bandwidth. The IoT application would run in the cloud, have access to all the data it needs, and wouldn’t be affected if the physical data sources were to go offline temporarily.

Most traffic between physical device and the cloud would stay at this cloud edge point, reducing impact on the cloud infrastructure. You could train machine-learning here to constantly improve the value and quality of the analytics you’re running. The specialized application logic needed to directly or indirectly interact with the physical web devices could also be deployed on these nodes, isolating access away from the cloud applications themselves.

This is what cloud-based IoT application developers want—a fully decoupled, always accessible virtual representation of the physical web that provides scalable machine learning and IoT value creation with a persistent, high-bandwidth cloud connection.

The Physical Edge Device Pattern

Many IoT devices have a certain amount of computing capability on the device itself—whether it’s fixed factory automation or a rail locomotive. Capital equipment like this is expensive and often require decades-long replacement cycles, so equipment control and operation—operational technology (OT)—trumps everything else, including IoT applications. The embedded computing capabilities of these devices are likely proprietary and are primarily focused on control systems. They also must function whether remote connectivity is available or not. Supervisory, monitoring, and job control interfaces may or may not be available and in most cases, are vendor- or industry-specific.

Any true IoT solution at the “physical edge” will provide full, secure access from physical web data streams to cloud services—or an on-premises Cloud Edge Node. It will be built in full collaboration with machine suppliers and operators, will protect stakeholder IP for both raw and derived data, and will, most importantly, prioritize proper, safe, and effective physical device operation above all else.

The Edge Gateway Pattern

What happens when cloud connectivity is unavailable? Typically, an “Edge Gateway Node” can be deployed near physical web devices. The Edge Gateway provides extensive local connectivity capabilities, including mesh networking, RFID, or a controller area network (CAN). It allows you to collect and process data at the edge, sending relevant data to the cloud app when it becomes available. Most of the “embedded-PC” class devices supported by cloud-based IoT platforms today fit this category, but many lack the rich local connectivity options needed to fully realize IoT capabilities.

The Need for Three

Going forward, IoT solutions that interact with physical web devices will likely include one or more of these edge nodes in addition to their cloud-based application foundations. As those solutions scale, the technologies will develop and specialize over time, providing additional capabilities and broader IoT value.

Brad Nicholas is the Lead IoT Architect at Uptake.