IIoT at the Smart Device Edge (family)

Type of Devices-

            Devices that live at the Smart Device Edge are characterized by having a small footprint yet being powerful enough to being able to many compute tasks at the edge.  They tend to have a minimum of 256 MB for a single node and can grow to the size of a small cluster.  These resources could be a router, hub, server, or gateway that are accessible.  This is as opposed to On-Prem Data Center Edge, the Service Provider Edge or Central Data Centers, which are much more powerful and have some type of physical security around them (a locked door to the server room).  The family is agnostic to the type of silicon that runs these devices, since the devices come from a wide variety of manufacturers and do a wide array of different things (ARM and x86 CPUs, TPU, GPU, etc.)  

Comprehension of the Uniqueness of the IIoT-

            There are many unique concepts that make the Industrial IoT/Industry 4.0 world.  Devices very widely in their age, OS, and compute abilities, with an assortment of legacy VMs and apps which need to run alongside modern containers and apps.   Thus this family is very varied in the devices it covers.  The devices are created to prioritize for uptime and the safety of the equipment and people who run them, thus the compute resources were designed to lessen latency and prioritize safety critical applications.  They handle a wide range of OT protocols and have a mix of On-Prem and Cloud back end systems that they can send messages to.  Yet, the control messages back to the devices themselves, need to be handled on the compute resource itself. 

Use Case Details:

Using the LF Edge Taxonomy white paper, most devices in the Industrial IoT are part of the Smart Device Edge, with some on the Constrained Device Edge.  This means that the device itself has at least some compute power, usually at least 256 MB of memory.  For the Constrained Device Edge, these devices have very limited compute power and instead pass the data to a more powerful device.

A simple UC example can get complicated very quickly-

The best way to illustrate this is with a simple example.  Imagine a temperature sensor and a fan connected to a Raspberry Pi.  The Raspberry Pi samples the temperature sensor once a minute and if the temperature is over 25C it turns on the fan.  It also writes this to an internal DataBase.  Once every ten minutes, it tries to send a message to a cloud instance, if that fails, the device will wait until the next cycle to try to send the data.  If there is success, it purges the DataBase and continues. 

In this scenario, the temperature sensor and the fan are Constrained Devices and the Raspberry Pi is the Smart Device.  The Smart Device has enough power to process the amount of data that is produced.  Obviously in the real Industrial IoT world, these devices would be customized to the need of the specific use case.  And while this UC works with the one device, but it would quickly fall apart at the IoT scale.  Imagine a 50 machines that are producing a product in plant.  On each device is a vibration sensor produces data at 10k Hz (10,000 reads/second).  And we need to make sure that the device does spin with vibrations outside of a tolerance.  Thus we need a Smart Device that is powerful to handle this much data and we need some type of software that can monitor this much data and be able to react.  Thus the requirements of the system are now much different than they were in our simple example and thus the equipment needs to change accordingly.  We will want something like a LF Edge's Fledge or EdgeX Foundry running on the Smart Device.  We expand our example to say that instead all of the sensor data going to one Smart Device, but instead they can only handle 5 sensors (because of the amount of data or distance between devices), we now have 10 Smart Devices and if we add more requirements, such as these devices are monitoring an oil pipeline and it costs $30,000 to do a truck-roll to update the software.  Now our requirements have greatly changed again.  Now we will want to add a piece of control (virtualization) software to each of the devices to allow us to push updates and monitor devices from a distance.  For this, we might want to add something like LF Edge's EVE, Open Horizon, SDO or some combination of them.  For all of these pieces, it is possible to use Open Source or some type of commercial software or a combination of them.

Why is the IIoT at the Smart Device Edge a family?

As you can tell from the above example the simple and a more complicated examples are very similar yet different and the the Solution Architect will need to work with customer to determine what is the best course of action based upon many different factors (regulations, safety, internet connectivity, maintenance schedules, physical access to the device, cost, among many others).  The IIoT at the Smart Device Edge family of blueprints is designed to help the solution architect and end user determine what works for them.  It is very possible that there is no perfect fit of the blueprints here, but most likely a combination of the blueprints will provide a complete solution.  With this in mind the blueprints are designed to be componentized so that they can be separated and combined in many different ways. 

• describe a baseline infrastructure
• horizontal infrastructure- market-tecture need to scope this out; draw the picture
• support to workload themes
  • computer vision, eg stream video
    • high bandwidth is needed
    • the killer app is to process this at the edge
  • machine intelligence, eg structured telemetry
    • many different protocols, 
    • varying amounts of data volume (eg vibration data vs temperature data)
• enable workload consolidation

Family- IIoT at the Smart Device Edge 

This is for the Family, Blueprint creators are welcome to join by adding their name. 

We are starting the election of a PTL 3 Sept, which will end in two weeks (17 Sept).  Anyone interested in becoming PTL just needs to self nominate themselves by putting Y in the correct column.  As per the Akraino Community process and directed by TSC, a blueprint which has only one nominee for Project Technical Lead (PTL) will be the elected lead once at least one committer seconds the nomination after the close of nominations.  If there are two or more, an election will take place.  

Contributors: 

Tina Tsou