Page History

PTL- Aaron Williams- beginning 17 Sept 2020

What is the Smart Device Edge-

            Using the LF Edge Taxonomy white paper, 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.)  

Image Added

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:

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 (hundreds to thousands of devices). 

Imagine 50 machines that are at a manufacturing plant.  On each device is a vibration sensor produces data at 1k Hz (1,000 reads/second).  And we need to make sure that the machine does not 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 and process 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 the equipment needs 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.  Adding 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 the solution has changed again.  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 Solution Architect will need to work with the 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 their needs are and how to create solution that works for them.  It is very possible that there is no perfect fit of the blueprints here, but there is 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. 

A Baseline Infrastructure

Image Added

The basic infrastructure for this family is Smart Edge Device that is connected to some type sensor (Southbound) and the device is able to communicate both Northbound to a Cloud or an on-Prem System.  Most Use Cases will extend this basic diagram to run some type of application in a container or VM. 

The killer apps for this family will applications that can take advantage of the compute power at the device edge.  Two examples would be Computer Vision and AI/MI.  For computer vision applications, a large pipe is needed to stream the video to the edge device, then it can process the video and send responses back to the edge components and/or send a filtered set back to the cloud. Having the ability to do compute at the edge allows for AI/MI at the edge, thus predictions can be created without leaving the device

Family- IIoT at the Smart Device Edge 

Use Case Details:

Use Case  -  Predictive Maintenance using a FLIR Camera

Attributes

...

Description

...

Informational

...

Type

...

New

...

New

...

Industry Sector

...

IoT Device Edge

...

Business driver

...

Predictive Maintenance

...

Business use cases

...

Many devices give off hints that they will need to have maintenance earlier than their schedule maintenance.  Through Machine Learning (ML), we can create models that will allow us to know that a device will soon need maintenance.  For many machines, we can gain a great deal of information on the health of the device by looking at the temperature of the device.  This requires collecting the data and then sending it to a Historian or similar device.  These data points can be sent to the cloud to be modeled.

Other requirements

• Need to take the current temperature of the device and react in near real time to rising temperature
  • Example: If over 150 C- send out a warning to a email list, show warning on a UI
    if over 180 C trigger light or horn
    if over 200 C trigger shutdown process

Other variations:

Monitoring restricted spaces

• If a human enters in a space, 
  • first level of restriction- sound an alarm and turn on lights
  • second level- start shutdown process

Predictive maintenance: There are many different types of models.  For example, many models do not need to be done in real time.  Thus, the data can be sent to the Cloud and processed.  The data is not time critical, so if there is a delay in sending/receiving data, the data will need to be stored and then sent when the network is available. 

Yet, there are many scenarios, where real time or near real time is required.  An example of this would be a machine reaching a maximum temperature.  As it approaches this, we would want to send out a warning and then if it reached this critical temperature, the device needs to be shut down.

For this type of scenario, there needs to be a server or space on the IoT gateway that can process the data in real time. 

...

Business Cost - Initial Build Cost Target Objective

...

Business Cost – Target Operational Objective

...

Security need

...

Regulations

...

Varies depending on local regulations

...

Other restrictions

...

Additional details

...

Use Case Attributes	Description	Informational
Type	New-approved March 2020
Blueprint Family - Proposed Name	Industrial IoT -at the Smart Device Edge	There are many possible UCs that would be IIoT, so these only are designed to handle Predictive Maintenance UCs could be done at the Industrial Smart Device Edge, so family might  need to be broken up at some point
Use Case	Predictive Maintenance using a FLIR CameraSee belowMaintenance	This family is focused on how to bring data into the smart device edge and then do some type of compute there on the device.
Blueprint proposed	Predictive Maintenance- Using FLIR Cameraa thermal imaging camera	This is the first proposed blueprint
Initial POD Cost (capex)	Varies widely depending on the Blueprint
Scale of Servers	one at the User Edge	Smart Device Edge size	Largest would be an IoT Gateway, with the smallest being the compute power of a Raspberry Pi.  These are very limited devices as compared to machines that are currently found at the On-Prem Data Center Edge.this is the IoT Gateway
Applications (Edge Virtual Network Functions)	EVE, Fledge
Power Restrictions	None/Varies	none for the FLIR, but another blueprint might need itThis could vary widely depending on the blueprint, but for most, it should not be a limiting factor.
Preferred Infrastructure orchestration	Docker/K8 - Container Orchestration OS - Linux
Additional Details

BluePrint (Species) - Predictive Maintenance- with a FLIR Camera

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

PTL- Aaron Williams- 17 September 2020 through 17 September 2021

Contributors: 

Contributors

Tina Tsou

Jeff BrowerTina Tsou