feature article
Subscribe Now

Living On the Edge

EdgeX Defines an “Edge” Framework

Ah, words… Simple audio utterances that contain meaning. Well, except when they don’t. Or when each of us parses a different meaning out of a given collection of phonemes, making even morphemes morph.

In our world of technology, in particular, we deal with inordinately complex concepts, and we have to find shorthand ways of referring to them, or else we’d forever be locked up with convoluted phrases like, “a single binary unit of information” instead of “bit.” And, in most cases, for purposes of communicating in the English language, we borrow from the vast English lexicon (or occasionally from other languages, but English has a rather large vocabulary from which to choose). We take words that mean some specific mundane thing – like “bit” – and leverage them for some technical concept that evokes the simple meaning of the word.

So, for example, when describing the overall architecture of the Internet of Things, we have several large-scale features that need names. We have “things” and we have the “cloud.” Drilling deeper, we have a big, giant network connecting it all together. And there are different places in that network that merit their own words. The middle of the network, where traffic volumes are enormous, is the “core.” And the IoT devices themselves are way out at the “edge” of the network.
Or are they?

We also suffer from some level of myopia, restricting the context of those words to some limited scope, outside of which the word choice no longer makes sense. And “edge” is one of those words.

OK… Exactly Where Are We Going with This?

I should probably pause to make this relevant. No, this isn’t a paean to the variety and flexibility of the English (or any other) lexicon. No, it’s stimulated out of true confusion on my part – until I received a contextual straightening out.

The topic at hand was a project named EdgeX, an effort put forth by the Linux Foundation. I say, “was,” because my confusion was past tense. EdgeX is present tense. Just to be clear. They describe themselves as, “The Open Interop Platform for the IoT Edge.” Their focus is the Industrial IoT. Sounds pretty straightforward in concept.

But looking closer (as we will in a moment), I was seeing a rather beefy stack – one that would never fit in the kinds of small devices that we might find out at the edge of the IoT. Upon inquiring about that, the explanation made sense, if being somewhat unsatisfying. It all goes to what you mean by “edge” and “IoT.”

The Edge of What?

Back in the earlier days when communications were taking off – when we popularized those drawings that had the mysterious “cloud” in the middle – there was a lot of focus on the core network. Those are the heavyweight pipes at the Center of Everything that push all the traffic around until it gets to… well, all the local networks around the core network. It would appear that these were two different contexts, and data would be handed off from the core network to the local network as it arrived. Or vice versa.

And where was that data handed off? At the edge. “The edge of what?” you ask. The edge of the core network. So the “edge” wasn’t the edge edge – the real edge where the whole network thing ended. It was the edge of one network, but the start of another. If you lived in the core, then whatever was outside that network was not your problem. You took stuff to the “edge” – to the edge of your world – and then it became someone else’s problem (and the vocabulary changed there too).

And so it is with the IoT. Yeah, there’s still that core network. So where is the “edge” in this context? No, not the actual edge (that would be too obvious); it’s where the internet meets the local network: at the gateway or hub.

To be clear, when it comes to the IoT, not everyone uses that meaning of edge; some do mean the real edge, beyond which there is no more. Which makes it even more confusing.

Oh, That Edge!

So this edge functionality, this interop, according to EdgeX, is not about actual IoT devices living out at the real edge of things. It’s about those local boxes to which all of the things that are truly at the edge will be connected. And they’re important for interop, since Things will plug into them, and the more Things are allowed to plug in, the more flexibility we have in configuring our IoT environment.

OK, so, now that we’ve expended numerous words expounding on the meaning of the word “edge,” let’s take a more specific look at what EdgeX is all about. The news had them releasing their first code batch, named “Barcelona.” It implements an architecture as shown below.

(Click to enlarge; image courtesy EdgeX Foundry)

The idea here is to implement a plug-and-play environment to which others can design so that unrelated devices made by companies that haven’t specifically set out to work together can, in fact, interoperate based on the underlying framework.

There are elements in this platform that are replaceable; they’re showed in lighter gray. The dark purple bits are the, well, core services (but not that core) that are central to the system. APIs standardize communication with those services, making it possible to add value by substituting out device, supporting, export, security, or management services.

And in each of the non-core segments, there are pre-defined elements – like specific communications protocols for talking to devices – as well as room for “additional services.” That keeps things flexible and allows for future growth at all levels.

Services are implemented as “microservices”; this allows them to operate in isolation so that, if one service goes south, it doesn’t mess up the other services. Or if someone hacks one service, they can’t necessarily break into another one. In an environment where each service may have a different author, this is critical.

There are four main core services:

  • The registry and configuration component keeps track of all of the installed microservices.
  • The metadata component is similar, but it keeps track of all of the sensors and other connected devices, including the type of data generated and where that data goes. It also tracks what commands apply to the connected devices. It doesn’t collect the data, however, nor does it send any commands to the devices. Those are handled by the next two components.
  • The core data component acts as a manager of and local repository for the data collected by sensors or any other generator of data. It can be referenced locally, or it can simply act as a data waystation pending transfer up to the cloud or to some other more permanent repository. To be clear, “permanent” is a relative term; the core data, even if temporary, is persistent.
  • Finally, the command component handles the direct issuing of commands to the devices. Given the RESTful nature of the interface, commands come as variations of GET and PUT.

Microservices can be created by developers using the EdgeX SDK; it, as well as created code, can be downloaded from the EdgeX Factory site.

Ideally, you end up with a flexible infrastructure that can be built upon with minimal risk of breaking what’s already working. Services can be loaded onto a particular hub or gateway according to the functions needed for its particular installation.

The remaining user problem that must be addressed is how someone, upon buying such a gateway, goes about provisioning it with the specific services required. Given the industrial focus, there are likely to be resources available for such configuration in a way that would probably not work for consumers, where the details of adding services would need to be completely transparent. (Or, wait, is it opaque? Gah! Words!) But that’s a problem for a system maker, not the framework.

This also allows for foggish implementations, keeping some data and calculation local – especially for time-sensitive operations.

Of course, fog operates next to the ground. Which breaks the “edge” metaphor. Which could mean we could return the meaning of “edge” to actual edge…

More info:
EdgeX Foundry

2 thoughts on “Living On the Edge”

Leave a Reply

featured blogs
Jul 28, 2021
The System Analysis Knowledge Bytes blog series will explore the capabilities and potential of the System Analysis tools offered by Cadence®. In addition to providing insight into the useful... [[ Click on the title to access the full blog on the Cadence Community site....
Jul 28, 2021
Here's a sticky problem. What if the entire Earth was instantaneously replaced with an equal volume of closely packed, but uncompressed blueberries?...
Jul 28, 2021
Hyperscale data centers are driving demand for high-bandwidth Ethernet protocols at speeds up to 800G to support HPC, AI, video streaming, and cloud computing. The post What's Driving the Demand for 200G, 400G, and 800G Ethernet? appeared first on From Silicon To Software....
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Electromagnetic Analysis for High-Speed Communication

Sponsored by Cadence Design Systems

When your team is driving the future of breakthrough technologies like autonomous driving, industrial automation, and healthcare, you need software that helps meet approaching deadlines and increasingly high-performance demands. Learn how a system analysis solution can provide accurate 3D modeling, electromagnetic simulation, and electrothermal simulation at the chip, package, PCB, and system level.

Click to learn more

featured paper

Configure the backup voltage in a reversible buck/boost regulator

Sponsored by Maxim Integrated

This application note looks at a reference circuit design using Maxim’s MAX38888, which provides a supercapacitor-based power backup in the absence of the system rail by discharging its stored charge. The backup voltage provided by the regulator from the super cap is 12.5% less than the system rail when the system rail is removed. This note explains how to maintain the backup voltage within 5% of the minimum SYS charge voltage.

Click to read more

featured chalk talk

Accelerating Physical Verification Productivity Part Two

Sponsored by Synopsys

Physical verification of IC designs at today’s advanced process nodes requires an immense amount of processing power. But, getting your design and verification tools to take full advantage of the compute resources available can be a challenge. In this episode of Chalk Talk, Amelia Dalton chats with Manoz Palaparthi of Synopsys about dramatically improving the performance of your physical verification process. 

Click here for more information about Physical Verification using IC Validator