Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

  • add in a couple more UCs for this
  • add in alignment with Akraino blueprints
  • 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

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 IIoT world.  But these devices very widely in their age, OS, 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:

<add in the taxonomy image from the white paper>


add in text explaining the smart device edge 



Family- IoT Device Edge-

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 could be done at the Industrial Smart Device Edge, so this might 
need to be broken up at some point 

Use Case

Predictive Maintenance 

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 a thermal imaging camera


This is the first proposed blueprint

Initial POD Cost (capex)

Varies widely depending on the Blueprint


Scale of Servers

Smart Device Edge sizeLargest 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.

Applications (Edge Virtual Network Functions)

EVE, Fledge


Power Restrictions

None/Varies

  • This 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




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.  

Committer

Committer

Company

 Committer Contact InfoTime Zone

Committer Bio

Committer Picture

Self Nominate for PTL (Y/N)

@bill hunt

Dianomic

bill@dianomic.com





Shiv Ramamurthi

ArmShiv.Ramamurthi@arm.com



Cplus Shen

Advantech

Cplus.Shen@advantech.com.tw





Ashwin GopalakrishnanDianomicashwin@dianomic.com



Erik NordmarkZededaerik@zededa.com



Daniel LazaroOSIsoftdlazaro@osisoft.com



Aaron WilliamsIndividualaaron@wi5s.comPacific

Y
Vladimir SuvorovAI Solutionshello.fleandr@gmail.comGMT +3



Contributors: 

Tina Tsou (Deactivated)




  • No labels