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
May 17, 2021
In the beginning there was the airfoil. Or more specifically, in 1968 it became clear that something new was needed to help design supercritical airfoils and wings. Today there is serious planning... [[ Click on the title to access the full blog on the Cadence Community site...
May 13, 2021
Samtec will attend the PCI-SIG Virtual Developers Conference on Tuesday, May 25th through Wednesday, May 26th, 2021. This is a free event for the 800+ member companies that develop and bring to market new products utilizing PCI Express technology. Attendee Registration is sti...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

Super Resolution with ARC EV Processor IP

Sponsored by Synopsys

Interested in upscaling images with AI? Join Gordon Cooper for an update on SR-GAN with ARC EV Processors.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

Bring a "Can-Do" Attitude to Your Industrial Drone Design

Sponsored by Maxim Integrated

Providing predictable and error-free communications, CAN bus networks have been the workhorse of the automobile industry for over thirty years. But they have recently found a new lease on life in other industrial applications, including drones. This design solution shows where and how CAN transceivers can be used in drone designs and explains why it is important that they come with high levels of electrical protection.

Click to read more

featured chalk talk

The Wireless Member of the DARWIN Family

Sponsored by Mouser Electronics and Maxim Integrated

MCUs continue to evolve based on increasing demands from designers. We expect our microcontrollers to do more than ever - better security, more performance, lower power consumption - and we want it all for less money, of course. In this episode of Chalk Talk, Amelia Dalton chats with Kris Ardis from Maxim Integrated about the new DARWIN line of low-power MCUs.

Click here for more information about Maxim Integrated MAX32665-MAX32668 UB Class Microcontroller