By: Petter Graff, CTO –

 A better model for organizing compute nodes and logic for IoT solutions

Edge, Mist, Fog, Cloud, etc. In the IoT world, we seem obsessed with the need to name the layer in which software runs. The most common definitions are:

  • Edge compute (or sometimes called Mist compute) is where our computers meet the sensors.
  • Fog compute is some intermediate layer between the edge computers and their final destination.
  • Cloud compute represents software running in some data center (either on-premise or at some compute provider such as Amazon, Google, Microsoft, etc.).

Although this model can be useful as an abstract reference layer, I find the naming convention too limiting for practical use. I have two observations that may help illustrate the problem:

  1. In some of our use cases, nodes can play the role of edge and fog simultaneously. For example: say we have a compute node installed in a base station. This node may be a child node of some compute node running in our data center and also play the role of a parent node of some computers running in vehicles in the field…. “Ah,” you may say, “that is a Fog node!” OK, but it also is connected to a set of sensors in the base station, playing the role of edge as well.
  2. Sometimes I have more than 3 layers. What do I call the layers now? Last week, I helped a customer that had identified no less than 12 layers from the sensors to the top level compute model.  Also, various layers along the way had some degree of direct sensor output.

I vote we stop using this limited nomenclature or at least avoid asking questions like “is this an edge node, a fog node, or a cloud node?” 

You may ask, what do we do instead?

At Pratexo, we don’t mind talking about layers, and every use case we have ever been involved with has layers. It is also often useful to use Edge/Fog/Cloud etc., to help convey some architectures. If the architecture has exactly 3 layers, that is. However, for each use case, naming the layers based on dimensions understood by the domain experts is most often more useful.

For example, we have a vehicle tracking system where we have installed a compute unit in a car that calculates things like fuel consumption, speed, direction, driver behavior, etc. We have a set of software running in some 5G base stations that processes the vehicle information and control traffic patterns for the concerned area. We also have a set of compute units installed in the control center of the city that dispatches resources to accident sites, control city traffic, etc. Finally we also have a statewide control system running in some statewide algorithms to calculate traffic and dispatch resources based on weather or other conditions. 

Now we need to name 4 layers. We could say that the vehicles are edge, the base station mist, the on-premise compute fog and the statewide compute cloud. It works, but doesn’t seem very meaningful to me. 

Here is one possibility for better naming based on where the software runs:

  • Using the physical location of the compute:
    • Vehicle layer
    • Base station layer
    • On-premise layer
    • AWS/GCP/Azure/… layer

I could also imagine talking about functions. In this case, the layers would have been organized the same way.

  • Using functions:
    • Vehicle layer
    • Local district layer
    • City layer
    • State layer

Although we ended up with the same layering, that is not always the case. Sometimes organizing physical locations and logical behavior may end up with very different layering. For example, say we deploy an AI model running in Apache Spark to calculate optimal routing behavior for the city. We may have compute nodes running in the base stations acting as Spark Worker Nodes and the parent node running on-premise (this would make a lot of sense as it would minimize the need for data shuffling). 

I can think of a parallel from another world. OMG organized their model models/languages into various layers. They used the layers M0..3. The idea was not to say Meta-Meta model, so instead, you put a number after the M to say that M2 is a Meta-Meta model. M0 means it was the physical objects you modeled (Meta * 0, meaning no meta). A useful model for OMG as they could arrange information, e.g.:

  • M0: the objects we want to describe
  • M1: The class diagram defining the objects (the meta-model for the objects)
  • M2: The UML class model (the definition of the language making up class model, or the meta-meta model for the objects)
  • M3: Meta Object Facilities (MOF) the languages in which we described the class models (or the meta-meta-meta model). 

There was no need for more layers as MOF could be described by itself. 

Great that the world had a reference model, but then the problems arose. If you are building a UML case tool, your M0 objects are M1 objects in the reference model. If you are building a meta-case tool, then your M0 objects are M2 objects in the meta-model.

A reference model that worked out a lot better in practice was a model described in Douglas Hofstadter’s book Gödel, Escher, Bach often called the Golden Braid model. Every object has a corresponding meta-object that describes it, every meta-object is an object. Voila, there you go. Flexible, practical, works in all cases; no need to name the layers.

I feel the same when specifying IoT solutions. I think more like this:

  1. It would be great if we had a compute unit  (hardware or software) in location X.
  2. The compute unit X should connect coordinate sensors or other compute units, which means it has some “south-bound” traffic.
  3. The compute unit X should take part of a bigger compute set which means it is controlled or has to convey information to a parent node. That is, it has to support “north-bound traffic”.

We also have east and west for swarms and other collaborations, but I’ll talk about this concept in a future blog post.

So now, we typically have a graph (most often a tree structure, but let’s be more general and think of it as a graph. We often have the need to abstract this graph by organizing the hardware/software into layers to help organize or discuss the solution. Now let’s name it:

Let’s call it my Golden Braid model of IoT!