Category

Use Cases

Akraino’s AI Edge-School/Education Video Security Monitoring Blueprint

By Akraino, Akraino Edge Stack, Blog, Use Cases

Written by Hechun Zhang, Staff Systems Engineer, Baidu; Akraino TSC member, and PTL of the AI Edge Blueprint; and Tina Tsou, Enterprise Architect, Arm and Akraino TSC Co-Chair

In order to support end-to-end edge solutions from the Akraino community, Akraino uses blueprint concepts to address specific Edge use cases. A Blueprint is a declarative configuration of the entire stack i.e., edge platform that can support edge workloads and edge APIs. In order to address specific use cases, a reference architecture is developed by the community.

The School/Education Video Security Monitoring Blueprint belongs to the AI Edge Blueprint family. It focuses on establishing an open source MEC platform that combined with AI capacities at the Edge. In this blueprint, latest technologies and frameworks like micro-service framework, Kata container, 5G accelerating, and open API have been integrated to build a industry-leading edge cloud architecture that could provide comprehensive computing acceleration support at the edge. And with this MEC platform, Baidu has expanded AI implementation across products and services to improve safety and engagement in places such as factories, industrial parks, catering services, and classrooms that rely on AI-assisted surveillance.

Value Proposition

  • Establish an open-source edge infrastructure on which each member company can develop its own AI applications, e.g. video security monitoring.
  • Contribute use cases which help customers adopt video security monitoring, AI city, 5G V2X, and Industrial Internet applications.
  • Collaborate with members who can work together to figure out the next big thing for the industry.

Use cases

Improved Student-Teacher Engagement

 

Using deep learning model training for video data from classrooms, school management can evaluate class engagement and analyze individual student concentration levels to improve real-time teaching situations.

Enhanced Factory Safety and Protection

Real-time monitoring helps detecting factory workers who might forget security gadgets, such as helmets, safety gloves, and so on, to prevent hazardous accidents in the workplace. Companies can monitor safety in a comprehensive and timely way, and used findings as a reference for strengthening safety management.

Reinforced Hygiene and Safety in Catering

Through monitoring staff behavior in the kitchen, such as smoking breaks and cell phone use, this solution ensures the safety and hygiene of the food production process.

Advanced Fire Detection and Prevention

Linked and networked smoke detectors in densely populated places, such as industrial parks and community properties, can help quickly detect and alert authorities to fire hazards and accidents.

Network Architecture

OTE-Stack is an edge computing platform for 5G and AI. By virtualization it can shield heterogeneous characteristics and gives a unified access of cloud edge, mobile edge and private edge. For AI it provides low-latency, high-reliability and cost-optimal computing support at the edge through the cluster management and intelligent scheduling of multi-tier clusters. And at the same time OTE-Stack makes device-edge-cloud collaborative computing possible.

Baidu implemented video security monitoring blueprints on the Arm infrastructure, including cloud-edge servers, hardware accelerators, and custom CPUs designed for world-class performance. Arm and Baidu are members of the Akraino project and use edge cloud reference stack of networking platforms and cloud-edge servers built on Arm Neoverse. The Arm Neoverse architecture supports a vast ecosystem of cloud-native applications and combines AI Edge blueprint for an open source mobile edge computing (MEC) platform optimized for sectors such as safety, security, and surveillance.

“Open source has now become one of the most important culture and strategies respected by global IT and Internet industries. As one of the world’s top Internet companies, Baidu has always maintained an enthusiastic attitude in open source, actively contributing the cutting edge products and technologies to the Linux foundation. Looking towards the future, Baidu will continue to adhere to the core strategy of open source and cooperate with partners to build a more open and improved ecosystem.” — Ning Liu, Director of AI Cloud Group, Baidu

In the 5G era, OTE-Stack has obvious advantages in the field of edge computing:

  • Large scale and hierarchical cluster management
  • Support third cluster
  • Lightweight cluster controller
  • Cluster autonomy
  • Automatic disaster recovery
  • Global scheduling
  • Support multi-runtimes
  • Kubernetes native support

For more information about this Akraino Blueprint, click here.  For general information about Akraino Blueprints, click here.

Breaking Down the Edge Continuum

By Blog, State of the Edge, Trend, Use Cases

Written by Kurt Rinehart, Director of Data Science at Section. This blog originally ran on the Section website. For more content like this, please click here.

There are many definitions of “the edge” out there. Sometimes it can seem as if everyone has their own version.

LF Edge, an umbrella organization that brings together industry leaders to build “an open source framework for the edge,” has a number of edge projects under its remit, each of which seeks to unify the industry around coalescing principles and thereby accelerate open source edge computing developments. Part of its remit is to define what the edge is, an invaluable resource for the edge community to coalesce around.

Latest LF Edge White Paper: Sharpening the Edge

In 2018, State of the Edge (which recently became an official project of LF Edge) put out its inaugural report, defining the edge using four criteria:

  • “The edge is a location not a thing;
  • There are lots of edges, but the edge we care about today is the edge of the last mile network;
  • This edge has two sides: an infrastructure edge and a device edge;
  • Compute will exist on both sides, working in coordination with the centralized cloud.”

Since that inaugural report, much has evolved within the edge ecosystem. The latest white paper from LF Edge, Sharpening the Edge: Overview of the LF Edge Taxonomy and Framework, expands on these definitions and moves on from simply defining two sides (the infrastructure and the device edge) to use the concept of an edge continuum.

The Edge Continuum

The concept of the edge continuum describes the distribution of resources and software stacks between centralized data centers and deployed nodes in the field as “a path, on both the service provider and user sides of the last mile network.”

In almost the same breath, LF Edge also describes edge computing as essentially “distributed cloud computing, comprising multiple application components interconnected by a network.”

We typically think of “the edge” or “the edges” in terms of the physical devices or infrastructure where application elements run. However, the idea of a path between the centralized cloud (also referred to as “the cloud edge” or “Internet edge”) and the device edge instead allows for the conceptualization of multiple steps along the way.

The latest white paper concentrates on two main edge categories within the edge continuum: the Service Provider Edge and the User Edge (each of which is broken down into further subcategories).

edge continuum diagram
Image source: LF Edge

The Service Provider Edge and the User Edge

LF Edge positions devices at one extreme of the edge continuum and the cloud at the other.

Next along the line of the continuum after the cloud, also described as “the first main edge tier”, is the Service Provider (SP) Edge. Similarly to the public cloud, the infrastructure that runs at the SP Edge (compute, storage and networking) is usually consumed as a service. In addition to the public cloud, there are also cellular-based solutions at the SP Edge, which are typically more secure and private than the public cloud, as a result of the differences between the Internet and cellular systems. The SP Edge leverages substantial investments by Communications Service Providers (CSPs) into the network edge, including hundreds of thousands of servers at Points of Presence (PoPs). Infrastructure at this edge tier is largely more standardized than compute at the User Edge.

The second top-level edge tier is the User Edge, which is on the other side of the last mile network. It represents a wider mix of resources in comparison to the SP Edge, and “as a general rule, the closer the edge compute resources get to the physical world, the more constrained and specialized they become.” In comparison to the SP Edge and the cloud where resources are owned by these entities and shared across multiple users, resources at the User Edge tend to be customer-owned and operated.

Moving from the Cloud to the Edge

What do we mean when we talk about moving from the cloud to the edge? Each of the stages along the edge continuum take you progressively closer to the end user. You have high latency and more compute in the centralized cloud versus low latency and less compute as you get closer to the User Edge. When we talk about moving from the cloud to the edge, it means we want to leverage the whole stack and not solely focus on the centralized cloud.

Let’s look at the most obvious use case: content delivery networks (CDNs). In the 1990s, Akamai created content delivery networks to allow localized websites to serve a global audience. A website based in New York could leverage Akamai’s distributed network of proxy servers and data centers around the world to be able to store their static assets globally, including HTML, CSS, JavaScript, video, and images. By caching these in Akamai’s distributed global points of presence (PoP), the website’s end users worldwide were guaranteed high availability and consistent performance.

These days, CDNs are considered to be only one layer in a highly complex Internet ecosystem. Content owners such as media companies and e-commerce vendors continue to pay CDN operators to deliver their content to end users. In turn, a CDN pays ISPs, carriers, and network operators for hosting its servers in their data centers. That’s the Service Provider Edge we’re talking about.

An edge compute platform is still a geographically distributed network, but instead of simply providing proxy servers and data centers, an edge compute platform also offers compute. How do we define this? Compute can be defined as many things, but essentially, it boils down to the ability to run workloads wherever you need to run them. Compute still gives you high availability and performance, but it also allows for the capability to run packaged and custom workloads positioned relatively spatially to users.

An edge compute platform leverages all available compute between the cloud provider and the end user, together with DevOps practices, to deliver traditional CDN and custom workloads.

Applying Lessons from the Cloud to the Edge

We can take the lessons we’ve learned in the cloud and apply them to the edge. These include:

  • Flexibility – At Section, we describe this as wanting to be able to run “any workload, anywhere”, including packaged and customized workloads;
  • Taking a multi-provider approach to deployments – This offers the opportunity to create a higher layer of abstraction. Infrastructure as Code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files as opposed to physical hardware configuration or interactive configuration tools. At Section, we have 6-7 different providers, from cloud providers to boutique providers to bare metal providers.
  • Applying DevOps practices – In order to provide the capabilities that the cloud has at the infrastructure edge, we need to enable developers to get insight and to run things at the edge at speed, just as they did in the cloud. This is DevOps. It’s important to be able to apply DevOps practices here since, “if you build it, you own it”. You want to make things open, customizable, and API-driven with integrations, so that developers can leverage and build on top of them.
  • Leveraging containerized workloads – Deploying containers at the edge involves multiple challenges, particularly around connectivity, distribution and synchronization, but it can be done, and in doing, allows you to leverage this architecture to deploy your own logic, not just pre-packaged ones. Containerization also offers:
    • Security
    • Standardization
    • Isolation; and
    • A lightweight footprint.
  • Insights and Visibility – We need to give developers deep, robust insight into what’s happening at the edge, just as we do in the cloud. The three pillars of observability are logs, metrics and tracing. An ELK stack can provide this, giving developers the invaluable ability to understand what is happening when things inevitably go wrong.

Edge Computing Use Cases in the Wild

There are many examples of use cases already operating at the Edge. A few of the many interesting ones out there include:

  • Facebook Live – When you see a live stream in your feed and click on it, you are requesting the manifest. If the manifest isn’t already on your local PoP, the request travels to the data center to get the manifest, and then fetches the media files in 1 second clips. ML algorithms operate on the 1 second clips to optimize them in real time to deliver the best, fastest experience for users.
  • Cloudflare Workers – These are Service Worker API implementations for the Cloudflare platform. They deploy a server-side approach to running JavaSCript workloads on Cloudflare’s global network.
  • Chick-fil-A – A surprising one. Chick-fil-A has been pushing into the device edge over the last couple of years. Each of their 20,000 stores has a Kubernetes cluster that runs there. The goal: “low latency, Internet-independent applications that can reliably run our business”, in addition to high availability for these applications, a platform that enables rapid innovation, and the ability to horizontally scale.

We’re Not Throwing Away the Cloud

One last thing to make clear: we’re not talking about throwing away the cloud. The cloud is going nowhere. We will be working alongside it, using it. What we’re talking about is moving the boundary of our applications out of the cloud closer to the end user, into the compute that is available there. And, as we’ve seen, we don’t need to throw away the lessons we’ve learned in the cloud; we can still use the tools that we’re used to, plus gain all the advantages that the edge continuum has to offer.

You can download the LF Edge taxonomy white paper here. You can also watch the LF Edge Taxonomy Webinar, which shares insight from the white paper, on our Youtube Channel. Click here to watch it now.  

OpenAirInterface End User Case Study – Running 5G on Akraino’s KNI Provider Access Edge Blueprint

By Akraino Edge Stack, Blog, Use Cases

Written by Ricardo Noriega, Project Team Lead, Akraino Kubernetes Native Infrastructure Blueprint Family, and Raymond Knopp,  Executive Committee member of the OpenAirInterface Alliance

Overview

Blueprints in the Akraino Kubernetes-Native Infrastructure (KNI) Blueprint Family leverage the best-practices and tools from the Kubernetes community to declaratively manage edge computing stacks at scale and with a consistent, uniform user experience from the infrastructure up to the services and from developer environments to production environments on bare metal or on public cloud.

One of the many use cases that the KNI blueprint family covers is the Provider Access Edge (PAE). The need for deploying mobile application on the edge is growing in latest times. Providing a platform that is capable of supporting deployment of mobile applications, using Kubernetes, and based on kubernetes tooling and declarative configuration from end to end is needed.

The OpenAirInterface project fosters a community of industrial as well as research contributors for software and hardware development for the core network (EPC) and access network and user equipment (EUTRAN) of 3GPP cellular networks. The OpenAirInterface alliance, has chosen the Akraino KNI PAE blueprint as the reference platform to develop, test and deploy its 4G and 5G open source mobile networks.

Key features on the Provider Access Edge blueprint

Telco / 5G network functions are among the more exigent Kubernetes workloads, but they are not unique: customers from high performance computing, high frequency trading, industrial control, et al. are asking for pretty much similar sets of capabilities.

This blueprint targets small footprint deployments able to host NFV (in particular vRAN) and MEC (e.g. AR/VR, machine learning, etc.) workloads. Its key features are:

  • Lightweight, self-managing clusters based on CoreOS and Kubernetes (OKD distro).
  • Support for VMs (via KubeVirt) and containers on a common infrastructure.
  • Application lifecycle management using the Operator Framework.
  • Support for multiple networks using Multus.
  • Support for high throughput interfaces using the SRIOV operator.
  • Support for real-time workloads.
  • Support for Stream Control Transmission Protocol (SCTP).

OpenAirInterface network deployment

The OpenAirInterface alliance has made a great effort on moving all the components that form a 4G/5G mobile network to the Kubernetes world. Building all the container images and writing the corresponding manifests to match a specific deployment model has been a tremendous work.

To support the 5G network in a production-like deployment, we configured the OpenShift based KNI PAE blueprint to segregate real-time and non-real-time compute workloads as well as management, control, and data plane traffic according to the following logical deployment architecture:

Conclusion

5G is designed to bring to the enterprise world as well as to the regular consumer, high throughput and low latency bandwidth that will enable the use cases of the future like IoT, autonomous cars, and many other applications deployed at the edge of the networks. The Akraino Kubernetes Native Infrastructure blueprint family allows to run these very demanding workloads on top, and OpenAirInterface has chosen us as the reference platform.

References

https://www.openairinterface.org/docs/workshop/8_Fall2019Workshop-Beijing/Talks/2019-12-05-DEFOSSEUX.pdf

Learn more about OpenAirInterface here. Learn more about Akraino here.

EdgeX Foundry Use Case: Wipro’s Surface Quality Inspection for a Manufacturing Plant

By Blog, EdgeX Foundry, Use Cases

Written by LF Edge members from Wipro. For more information about Wipro, visit their website.

The use case is “Automated surface quality inspection” for a manufacturing plant that produces “Piston Rods” used in different applications like Utility, Mining, Construction and Earth Moving.

In the manufacturing plant, the production of piston rods goes through multiple stages like induction hardening, friction welding, threading & polishing.  Each of these stages have a quality checkpoint to detect defects in early stages and to ensure that the rods produced are in line with design specifications & function properly.  After it goes through rigorous multi stage process, it reaches final station where surface level quality inspection happens.  At this stage, the quality inspection happens manually, requiring highly skilled & experienced human inspector to look for different types of defects like scratches, material defects & handling defects on the surface of rods.  Based on the final quality inspection results, it goes either to packaging & shipment area or to rework or scrap area.

Quality check at every stage is extremely critical to prevent quality problems down the line leading to recalls & reputational damages.  The problem with manual inspections – they are costly, time consuming and heavily dependent on human intelligence & judgement.  “Automated surface quality inspection” is an image analytics solution based on AI / ML that helps overcome these challenges.  The solution identifies and classifies defects based on image analytics to enable quality assessment and provides real-time visibility to Key Performance Indicators through dashboards to monitor plant performance.

EdgeX architectural tenets, production grade readily available edge software stack, visibility of long term support with bi-annual release roadmap and user friendly licensing for commercial deployments made us adopt EdgeX as the base software stack.

The readily available IoT gateway functionalities helped us focus more on building business application specific components than the core software stack needed for an edge gateway.  This helped us in rapid development of proof of concept for the use case we envisioned.

Key components of the solution include:

  • Edge Gateway hardware, Industrial grade camera & a sensor to detect piston rods placed in final quality inspection station
  • Software components:
    • Gateway powered by EdgeX software stack with enhancements to support the use case
    • Deep learning model trained with previously analyzed & classified defects
    • Intel’s OpenVino toolkit for maximizing inference performance on the edge gateway
    • EdgeX Device Service Layer enhancements to enable missing southbound connectivity
    • Automated decision making in the edge by leveraging EdgeX provided local analytics capability
    • EdgeX AppSDK customizations to connect to business applications hosted on cloud
    • Manufacturing Performance Dashboard to define, create and monitor Key Performance Indicators

Once the rod reaches inspection station, the gateway triggers the camera to take surface pictures.  The image captured is fed into the inference engine running on gateway, which looks for the presence of different types of surface defects.  The inference output is fed into the business application hosted on cloud to provide actionable insights with rich visual aids.

The analysis of historical data for similar pattern of defects, correlating data from OT systems with inference output for a given time period and providing feedback to OT systems for potential corrective actions are possible future enhancements.

Benefits:

  • Reduced inspection cost: Automated quality inspections, reduced need for manual inspection
  • Centralized management: Real time visibility to plant operations from remote locations
  • Consistent performance: Less dependency on human judgement, which varies from one person to another
  • Reduced inspection time: Consistent & reliable results in a much shorter time
  • Learning on the go: Continuous retraining of deep learning models make automated inspections accurate & closer to reality
  • Available 24 x 7

If you have questions or would like more information about this use case or LF Edge member Wipro, please email naga.shanmugam@wipro.com.

Winning GT3 Racing with LF Edge’s Fledge

By Blog, Fledge, Use Cases

Optimizing machine operations using Industrial IoT Fledge with Google Cloud, ML and state-of-the-art digital twins and simulators

Gradient Racing is a professional auto racing team based in Austin, Texas.  One of Honda’s customers for NSX GT3 Evo, Gradient is committed to using cutting edge technology to gain an edge in GT racing.

Modern race cars have thousands of adjustable parameters in their suspension, aerodynamics, transmission and other systems.  Finding the perfect configuration of these parameters for a given driver, track and race strategy is key to winning races. In GT racing, this has been more art than science, with drivers making multiple test runs and working with the race team to adjust the car based on feel.

Like Formula One and Nascar, Gradient wanted to bring state-of-the-art simulation technology to bear on this problem, believing that it would allow them to configure the car far more precisely. To do this, they engaged Motorsports.ai, a leader in racing modeling.

Creating a Virtual Racing Environment

Motorsports.ai’s goal was to create a full simulation environment of the race: a simulated driver, a simulated car and a digital twin of the track.  While car simulation software was commercially available, Motorsports.ai decided to use machine learning technology to develop an AI driver that would react to conditions in the same way as Gradient’s human driver.

Motorsports.ai deployed the Linux Foundation’s Fledge for three functions.  First, to collect the massive amount of data required to train the machine learning system. Second, to validate the race simulations of car, driver and track.  Last, to help validate the digital twin of each race track.  Originally developed by Dianomic Systems, Fledge joined LF Edge, an umbrella organization that aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system, last year. Fledge is an open-source Industrial IoT framework to collect sensor data, enhance it with meta information, run ML models on the edge and reliably transport data  to central or cloud-based processing systems. In a matter of weeks, Motorsports.ai developed the plugins needed to interface Fledge with the race car’s CAN Bus and Eclipse Cyclone DDS interfaces to over 2000 in-car sensors..

The human driver made multiple test runs on the track to determine his reaction to different conditions. Twenty times a second, Fledge collected readings on every aspect of car performance, as well as driver actions such as gas pedal and brake pressure, steering angle and gear changes.  Fledge enhanced each reading with the precise timestamp and GPS location of the car on the track.  Overall, Fledge collected more than 1GB of data on each test run, which it buffered and automatically transmitted to Google Cloud at the end of the run.  Motorsports.ai fed this data into TensorFlow running on a 20 node Google Kubernetes Engine cluster to validate the digital twin, and improve the accuracy of the predictions.

To build the model, Motorsports.ai integrated Fledge into a highly accurate simulation, and virtual prototyping environment to collect the same data as was collected in the physical car. Using TensorFlow, they then run distributed machine learning jobs using the KubeFlow framework on the aforementioned kubernetes cluster. Fledge is used to manage the sensor data from both the actual and virtual track runs. Motorsports.ai uses these results to provide predictions that ensure a competitive performance.

A key attribute for a digital twin is validation, and verification, which in this case requires precise mapping of the track surface type. The coefficient of friction between the car’s tires and track varies at each venue, the surface could be asphalt, concrete, painted, or all of the above. To identify the surface type for the digital twin, an Intel RealSense camera was deployed on the car, oriented to the track.  ML models running on the NVIDIA Jetson Xavier platform were then used to identify surface categories while Fledge added the telemetry, and timestamp to the ML models surface type category predictions.

Winning the Race

Gradient used the Motorsports.ai simulation to optimize suspension and alignment settings for every race in 2019.  The simulation enabled far more rigorous tuning than their previous manual method.  Instead of building a configuration based on a few laps and driver “feel”, they were able to run tens of thousands of simulations using precise measurement.  They were able to investigate conditions that had not yet been experienced on the actual track and ensure that they could compete effectively in them.

For example, for tire camber alone they ran 244 simulations, testing the camber of each tire at 0.1° increments through a range of -3.0° to +3.0°.  All told, Gradient simulated more than 10,000 track runs for each race, orders of magnitude more than would have been possible using a human driver.

The results showed on the scoreboard. Gradient broke the Circuit of the Americas track record by over 1.1 seconds and the Mid-Ohio Sports Car Course record by more than 1 second. They continued their success at other races and took home the national GTB1 championship title of the 2019 Pirelli Triple Trofeo.

To learn more about Fledge, visit https://www.lfedge.org/projects/fledge/, get the code here, or engage with the community on Slack (#fledge).  To learn more about LF Edge, visit https://www.lfedge.org/.

Edge computing architecture and use cases

By Blog, LF Edge, Use Cases

Written by By Jason Gonzalez, Jason Hunt, Mathews Thomas, Ryan Anderson, Utpal Mangla with LF Edge Premier Member Company IBM 

This blog originally ran on the IBM website. For more articles from IBM, visit https://developer.ibm.com/articles/.

Developing new services that take advantage of emerging technologies like edge computing and 5G will help generate more revenue for many businesses today, but especially for telecommunications and media companies. IBM works with many telecommunications companies to help explore these new technologies so that they can better understand how the technologies are relevant to current and future business challenges.

The good news is that edge computing is based on an evolution of an ecosystem of trusted technologies. In this article, we will explain what edge computing is, describe relevant use cases for the telecommunications and media industry while describing the benefits for other industries, and finally present what an end-to-end architecture that incorporates edge computing can look like.

What is Edge Computing?

Edge computing is composed of technologies take advantage of computing resources that are available outside of traditional and cloud data centers such that the workload is placed closer to where data is created and such that actions can then be taken in response to an analysis of that data. By harnessing and managing the compute power that is available on remote premises, such as factories, retail stores, warehouses, hotels, distribution centers, or vehicles, developers can create applications that:

  • Substantially reduce latencies
  • Lower demands on network bandwidth
  • Increase privacy of sensitive information
  • Enable operations even when networks are disrupted

To move the application workload out to the edge, multiple edge nodes might be needed, as shown in Figure 1.

Figure 1. Examples of edge nodes

Example of edge nodes

These are some of the key components that form the edge ecosystem:

  • Cloud
    This can be a public or private cloud, which can be a repository for the container-based workloads like applications and machine learning models. These clouds also host and run the applications that are used to orchestrate and manage the different edge nodes. Workloads on the edge, both local and device workloads, will interact with workloads on these clouds. The cloud can also be a source and destination for any data that is required by the other nodes.
  • Edge device
    An edge device is a special-purpose piece of equipment that also has compute capacity that is integrated into that device. Interesting work can be performed on edge devices, such as an assembly machine on a factory floor, an ATM, an intelligent camera, or an automobile. Often driven by economic considerations, an edge device typically has limited compute resources. It is common to find edge devices that have ARM or x86 class CPUs with 1 or 2 cores, 128 MB of memory, and perhaps 1 GB of local persistent storage. Although edge devices can be more powerful, they are the exception rather than the norm currently.
  • Edge node
    An edge node is a generic way of referring to any edge device, edge server, or edge gateway on which edge computing can be performed.
  • Edge cluster/server
    An edge cluster/server is a general-purpose IT computer that is located in a remote operations facility such as a factory, retail store, hotel, distribution center, or bank. An edge cluster/server is typically constructed with an industrial PC or racked computer form factor. It is common to find edge servers with 8, 16, or more cores of compute capacity, 16GB of memory, and hundreds of GBs of local storage. An edge cluster/server is typically used to run enterprise application workloads and shared services.
  • Edge gateway An edge gateway is typically an edge cluster/server which, in addition to being able to host enterprise application workloads and shared services, also has services that perform network functions such as protocol translation, network termination, tunneling, firewall protection, or wireless connection. Although some edge devices can serve as a limited gateway or host network functions, edge gateways are more often separate from edge devices.

IoT sensors are fixed function equipment that collects and transmits data to an edge/cloud but does not have onboard compute, memory, and storage. Containers cannot be deployed on them for this reason. These edge devices connect to the different nodes but are not reflected in Figure 1 as they are fixed-function equipment.

With a basic understanding of edge computing, let’s take a brief moment to discuss 5G and its impact on edge computing before we discuss the benefits and challenges around edge computing.

Edge Computing and 5G

The advent of 5G has made edge computing even more compelling, enabling significantly improved network capacity, lower latency, higher speeds, and increased efficiency. 5G promises data speeds in excess of 20 Gbps and the ability to connect over a million devices per square kilometer.

Communications service providers (CSPs) can use edge computing and 5G to be able to route user traffic to the lowest latency edge nodes in a much more secure and efficient manner. With 5G, CSPs can also cater to real-time communications for next-generation applications like autonomous vehicles, drones, or remote patient monitoring. Data intensive applications that require large amounts of data to be uploaded to the cloud can run more effectively by using a combination of 5G and edge computing.

In the advent of 5G and edge computing, developers will need to continue to focus on making native cloud applications even more efficient. The continual addition of newer and smaller edge devices will require changes to existing applications so that enterprises can fully leverage the capabilities of 5G and edge computing. In some cases, applications will need to be containerized and run on a very small device. In other cases, the virtualized network components need to be redesigned to take full advantage of the 5G network. Many other cases exist that require evaluation as part of the application development roadmap and future state architecture.

Benefits and challenges of edge computing

As emerging technologies, 5G and edge computing bring many benefits to many industries, but they also bring some challenges along with them.

Core benefits

The benefits of edge computing technology include these core benefits:

  • Performance: Near instant compute and analytics at the edge lowers latency, and therefore greatly increasing performance. With the advent of 5G, it is possible to rapidly communicate with the edge, and applications that are running at the edge can quickly respond to the ever-growing demand of consumers.
  • Availability: Critical systems need to operate irrespective of connectivity. There are many potential points of failure with the current communications flow. These points of failure include the company’s core network, multiple hops across multiple network nodes with security risks along the network paths, and many others. With edge, with the communication primarily between the consumer/requestor and the device/local edge node, there is a resulting increase in availability of the systems.
  • Data security: In edge computing architectures, the analytics data potentially never leaves the physical area where it is gathered and is used within the local edge. Only the edge nodes need to be primarily secured, which makes it easier to manage and monitor, which means that the data is more secure.

Additional benefits, with additional challenges

These additional benefits do not come without additional challenges, such as:

  • Managing at scale
  • Making workloads portable
  • Security
  • Emerging technologies and standards

Managing at scale

As workload locations shift when you incorporate edge computing, and the deployment of applications and analytics capabilities occur in a more distributed fashion, the ability to manage this change in an architecturally consistent way requires the use of orchestration and automation tools in order to scale.

For example, if the application is moved from one data center with always available support to 100’s of locations at the local edge that are not readily accessible or not in a location with that kind of local technical support, how one manages the lifecycle and support of the application must change.

To address this challenge, new tools and training for technical support teams will be needed to manage, orchestrate, and automate this new complex environment. Teams will require more than the traditional network operations tools (and even beyond software-defined network operations tools), as support teams will need tools to help manage application workloads in context to the network in various distributed environments (many more than previously), which will each have differing strengths and capabilities. In future articles in this series, we will look at these application and network tools in more details.

Making workloads portable

To operate at scale, the workloads being considered for edge computing localization need to be modified to be more portable.

  • First, size does matter. Since reducing latency requires moving the workload closer to the edge and moving it to the edge components will mean less compute resources to run the workload, the overall size of various workloads might limit the potential of edge computing.
  • Second, adopting a portability standard or set of standards can be difficult with many varied workloads to consider. Also, the standard should allow for management of the full lifecycle of the application, from build through run and maintain.
  • Third, work will need to be done on how best to break up workloads into sub-components to take advantage of the distributed architecture of edge computing. This would allow for the running of certain parts of workloads to run on an edge device with others running on an edge cluster/server or any other distribution across edge components. In a CSP, this would typically include migrating to a combination of network function virtualization (for network workloads) and container workloads (for application workloads and in the future, network workloads), where applicable and possible. Depending on the current application environment, this move might be a large effort.

To address this challenge in a reasonable way, workloads can be prioritized based on a number of factors, including benefit of migration, complexity, and resource/time to migrate. Many network and application partners are already working on migrating capabilities to container-based approaches, which can aid in addressing this challenge.

Security

While Data Security is a benefit in that the data can be limited to certain physical locations for specific applications, overall security is an additional challenge when adopting edge computing. Device edge physical devices might not have the ability to leverage existing security standards or solutions due to their limited capabilities.

So, to address these security challenges, the infrastructure upstream in the local edge might have additional security concerns to address. In addition, with multiple device edges, the security is now distributed and more complex to handle.

Emerging technologies and standards

With many standards in this ecosystem newly created or quickly evolving, it will be difficult to maintain technology decisions long term. The decision of a specific edge device or technology might be superseded by the next competing device, making it a challenging environment to operate in. With the right tools in place to address management of these varied workloads along with their entire application lifecycle, it can be an easier task to introduce new devices or capabilities or replace existing devices as the technologies and standards evolve.

Cross Industry Use Cases

In any complex environment, there are many challenges that occur and many ways to address them. The evaluation of whether a business problem or use case could or should be solved with edge computing will need to be done on a case by case basis to determine whether it makes sense to pursue.

For reference, let’s discuss some potential industry use cases for consideration, both examples and real solutions. A common theme across all these industries is the network that will be provided by the CSP. The devices with applications need to operate within the network and the advent of 5G makes it even more compelling for these industries to start seriously considering edge computing.

Use case #1: Video Surveillance

Using video to identify key events is rapidly spreading across all domains and industries. Transmitting all the data to the cloud or data center is expensive and slow. Edge computing nodes that consist of smart cameras can do the initial level of analytics, including recognizing entities of interest. The footage of interest can then be transmitted to a local edge for further analysis and respond appropriated to footage of interest including raising alerts. Content that cannot be handled at the local edge can be sent to the cloud or data center for in-depth analysis.

Consider this example: A major fire occurs, and it is often difficult to differentiate humans from other objects burning. In addition, the network can become heavily loaded in such instances. With edge computing, cameras that are located close to the event can determine whether a human is caught in the fire by identifying characteristics typical of a human being and clothing that humans might normally wear which might survive the fire. As soon as the camera recognizes a human in the video content, it will start transmitting the video to the local edge. Hence, the network load is reduced as the transmission only happens when the human is recognized. In addition, the local edge is close to the device edge so latency will be almost zero. Lastly, the local edge can now contact the appropriate authorities instead of transmitting the data to the data center which will be slower and since the network from the fire site to the data center might be down.

Figure 2. Depiction of intelligent video example

Image of firefighters in a fire

Use case #2: Smart Cities

Operating and governing cities has become a challenging mission due to many interrelated issues such as increasing operation cost from aging infrastructure, operational inefficiencies, and increasing expectations from a city’s citizens. Advancement of many technologies like IoT, edge computing, and mobile connectivity has helped smart city solutions to gain popularity and acceptance among a city’s citizens and governance alike.

IoT devices are the basic building blocks of any smart city solution. Embedding these devices into the city’s infrastructure and assets helps monitor infrastructure performance and provides insightful information about the behavior of these assets. Due to the necessity to provide real-time decision and avoid transmitting a large amount of sensor data, edge computing becomes a necessary technology to deliver city’s mission critical solutions such as traffic, flood, security and safety, and critical infrastructure monitoring.

Use case #3: Connected Cars

Connected cars can gather data from various sensors within the vehicle including user behavior. The initial analysis and compute of the data can be executed within the vehicle. Relevant information can be sent to the base station that then transmits the data to the relevant endpoint, which might be a content delivery network in the case of a video transmission or automobiles manufacturers data center. The manufacturer might also have relationship with the CSP in which case the compute node might be at the base station owned by the CSP.

Use case #4: Manufacturing

Rapid response to manufacturing processes is essential to reduce product defects and improve efficiencies. Analytic algorithms monitor how well each piece of equipment is running and adjust the operating parameters to improve its efficiency. Analytic algorithms also detect and predict when a failure is likely to occur so that maintenance can be scheduled on the equipment between runs. Different edge devices are capable of differing levels of processing and relevant information can be sent to multiple edges including the cloud.

Consider this example: A manufacturer of electric bicycles is trying to reduce downtime. There are over 3,000 pieces of equipment on the factory floor including presses, assembly machines, paint robots and conveyers. An outage in a production run costs you $250,000 per hour. Operating at peak efficiency and with no unplanned outages is the difference between having profit and not having profit. To operate smoothly, the factory needs the following to run at the edge:

  • Analytic algorithms that can monitor how well each piece of equipment is running and then adjust the operating parameters to improve efficiency.
  • Analytic algorithms that can detect and predict when a failure is likely to occur so that maintenance can be scheduled on the equipment between runs.

Predicting failure can be complex and requires the customized models for each use case. For one example how these types of models can be created, refer to this code pattern, “Create predictive maintenance models to detect equipment breakdown risks.” Some of these models need to run on the edge, and our next set of tutorials will explain how to do this.

Figure 3. Depiction of manufacturing example

Image of manufacturing floor

Overall Architecture

As we discussed earlier, edge computing consists of three main nodes:

  1. Device edge, where the edge devices sit
  2. Local edge, which includes both the infrastructure to support the application and also the network workloads
  3. Cloud, or the nexus of your environment, where everything comes together that needs to come together

Figure 4 represents an architecture overview of these details with the local edge broken out to represent the workloads.

Figure 4. Edge computing architecture overview

Edge computing architecture overview

Each of these nodes is an important part of the overall edge computing architecture.

  1. Device Edge The actual devices running on-premises at the edge such as cameras, sensors, and other physical devices that gather data or interact with edge data. Simple edge devices gather or transmit data, or both. The more complex edge devices have processing power to do additional activities. In either case, it is important to be able to deploy and manage the applications on these edge devices. Examples of such applications include specialized video analytics, deep learning AI models, and simple real time processing applications. IBM’s approach (in its IBM Edge Computing solutions) is to deploy and manage containerized applications on these edge devices.
  2. Local Edge
    The systems running on-premises or at the edge of the network. The edge network layer and edge cluster/servers can be separate physical or virtual servers existing in various physical locations or they can be combined in a hyperconverged system. There are two primary sublayers to this architecture layer. Both the components of the systems that are required to manage these applications in these architecture layers as well as the applications on the device edge will reside here.

    • Application layer: Applications that cannot run at the device edge because the footprint is too large for the device will run here. Example applications include complex video analytics and IoT processing.
    • Network layer: Physical network devices will generally not be deployed due to the complexity of managing them. The entire network layer is mostly virtualized or containerized. Examples include routers, switches, or any other network components that are required to run the local edge.
  3. Cloud
    This architecture layer is generically referred to as the cloud but it can run on-premise or in the public cloud. This architecture layer is the source for workloads, which are applications that need to handle the processing that is not possible at the other edge nodes and the management layers. Workloads include application and network workloads that are to be deployed to the different edge nodes by using the appropriate orchestration layers.

Figure 5 illustrates a more detailed architecture that shows which components are relevant within each edge node. Duplicate components such as Industry Solutions/Apps exist in multiple nodes as certain workloads might be more suited to either the device edge or the local edge and other workloads might be dynamically moved between nodes under certain circumstances, either manually controlled or with automation in place. It is important to recognize the importance of managing workloads in discreet ways as the less discreet, the more limited in how we might deploy and manage them.

While a focus of this article has been on application and analytics workloads, it should also be noted that network function is a key set of capabilities that should be incorporated into any edge strategy and thus our edge architecture. The adoption of tools should also take into consideration the need to handle application and network workloads in tandem.

Figure 5. Edge computing architecture overview – Detailed

Edge computing architecture detailed overview

We will be exploring every aspect of this architecture in more detail in upcoming articles. However, for now, let’s take a brief look at one real implementation of a complex edge computing architecture.

Sample implementation of an edge computing architecture

In 2019, IBM partnered with Telecommunications companies and other technology participants to build a Business Operation System solution. The focus of the project was to allow CSPs to manage and deliver multiple high-value products and services so that they can be delivered to market more quickly and efficiently, including capabilities around 5G.

Edge computing is a part of the overall architecture as it was necessary to provide key services at the edge. The following illustrates the implementation with further extensions having since been made. The numbers below refer to the numbers in Figure 6:

  1. A B2B customer goes to portal and orders a service around video analytics using drones.
  2. The appropriate containers are deployed to the different edge nodes. These containers include visual analytics applications and network layer to manage the underlying network functionality required for the new service.
  3. The service is provisioned, and drones start capturing the video.
  4. Initial video processing is done by the drones and the device edge.
  5. When an item of interest is detected, it is sent to the local edge for further processing.
  6. At some point in time, it is determined that a new model needs to be deployed to the edge device as new unexpected features begin to appear in the video so a new model is deployed.
Figure 6. Edge computing architecture overview – TM Forum Catalyst Example

Edge computing architecture overview TM Forum Catalyst Example

As we continue to explore edge computing in upcoming articles, we will focus more and more on the details around edge computing, but let’s remember that edge computing plays a key role as part of a strategy and architecture, an important part, but only one part.

Conclusion

In this brief overview of edge computing technology, we’ve shown how edge computing is relevant to challenges faced by many industries, but especially the telecommunications industry.

The edge computing architecture identifies the key layers of the edge: the device edge (which includes edge devices), the local edge (which includes the application and network layer), and the cloud edge. But we’re just getting started. Our next article in this series will dive deeper into the different layers and tools that developers need to implement an edge computing architecture.