Category

EdgeX Foundry

EdgeX Foundry Device Actuation from the Cloud

By Blog, EdgeX Foundry

Written by Jason Bonafide, EdgeX Foundry Contributor and Principal Software Engineer at Dell Technologies

EdgeX Foundry is a platform that serves as middleware in edge computing – serving between physical sensing and actuating devices and our information technology (IT) systems. Edgex’s interoperability enables communication between real world devices with simplicity in mind.

EdgeX Foundry is composed of several interoperable service layers. The layer that we will focus on in this tutorial is called Device Services Layer. The role of a Device Service is to connect “things” (sensors and devices) into EdgeX. For those looking to establish communication between devices and perform actions on conditional system-state, this tutorial is for you!

At Dell Technologies, we wanted to establish bi-directional communication between simulated devices on the edge (in an isolated network) with EdgeX Foundry. This enabled us to deploy a single up-to-date EdgeX Foundry cluster in VMWare’s One Cloud. This would speed up the process in bootstrapping systems on the edge which can showcase the variety of protocols supported by EdgeX. Demonstrating this flow, is the goal of this tutorial.

Tools and Technologies

While this tutorial aims to suit the needs of a variety of setups, below are used in this tutorial:

System Overview

Figure A contains the following components:

  • MQTT Device Service: Application which connects our Temperature Sensor to EdgeX.
  • Temperature Sensor: Simulated MQTT device on the edge.
  • EdgeX Foundry: EdgeX Core Services which handle the device readings, data, and actuation.

Device Overview

EdgeX Foundry’s MQTT Device Service leverages 3 topics when integrating a device with the platform:

  • Device-list Protocol Topic: This topic is used by MQTT Device Service for invoking a command on the device. In our example, we refer to this topic as the CommandTopic. This configuration can be modified at toml.
  • Driver IncomingTopic: This topic is by MQTT Device Service for receiving data, and publishing the data to core-data for persistence. This configuration can be modified at toml.
  • Driver ResponseTopic: This topic is used by core-command in receiving responses from the device actuation. This configuration is can be modified at toml.

Simulated Temperature Sensor Controller Device

  • Publishes temperature every 5 seconds to DataTopic.
  • Subscribes to CommandTopic which contains commands from edgex-core-command.
  • Publishes response for inbound command to RepsonseTopic.

This application used to simulate a temperature sensor can be found here.

Defining Device Profiles

As a pre-requisite to configuring the MQTT Device Service, we will need to define the Device Profiles for the devices.

A Device Profile defines the device’s values and operation methods (Read or Write). The device values and operation methods are essential in defining the “what” and “how” we can begin to tell EdgeX Foundry how it can interact with our devices.

Each Device Profile contains the following sections:

  • Identification: fields which pertain to the identification of a Device Profile.
  • DeviceResources: specification of sensor values within a device which may be read from or written to either individually or as part of a deviceCommand.
  • DeviceCommands: defines access to read and writes for simultaneous device resources.
  • CoreCommands: specifies the commands which are available via the core-command microservice.

Temperature Sensor Device Profile

# Identification properties
name: “TemperatureSensor”
manufacturer: “Generic”
model: “MQTT-123”

# Labels that we can use for filtering especially when invoking endpoints throughout the microservices.
labels:
– “temperature”
– “sensor”
– “controller”
– “mqtt”
description: “Simulated temperature sensor controller device”

# The Sensor is a simple one which only provides read-only access to its constantly updating temperature value.
deviceResources:
– name: temperature
description: “Sensor temperature value”
properties:
value:
{ type: “string”, “readWrite”: “R” }
units:
{ type: “string”, readWrite: “R” }

# Commands that we are concerned with in regards to interacting with the device.
deviceCommands:
– name: temperature
get:
– { index: “1”, “operation”: “get”, deviceResource: “temperature” }

# Defining of endpoints within core-command that we can use to interact with the sensor.
coreCommands:
– name: temperature
get:
path: “/api/v1/device/{deviceId}/temperature”

# 200 response with the temperature value in the response.
responses:
– code: “200”
description: “Get the temperature”
expectedValues: [ “temperature” ] – code: “500”
description: “internal server error”
expectedValues: []

Configuring MQTT Device Service

EdgeX Foundry offers an MQTT Device Service in which we will configure for our devices.

Host Configuration

While we intend to communicate with our device on a local network, we will still want to configure the Host for device-mqtt-go to be localhost. Later on in this tutorial, we will talk about port-forwarding to this process.

Each system may look different as to where you can find EdgeX and how you may connect to it. Be sure to update the Host and Port configuration properties for the clients. The device service will need to talk to some Core EdgeX Services.

Device Configuration

We leverage [[DeviceList]] to create our pre-defined Temperature Sensor.

In this section, we flesh out the device’s metadata.

  • Name: TemperatureSensor
  • Profile: TemperatureSensor
  • Description = ‘Simulated MQTT Temperature Sensor device’
  • Labels = [ ‘MQTT’, ‘Temperature’, ‘Sensor’ ]

Next we define MQTT protocol configuration:

  • Schema: tcp
  • Host: [MQTT Borker Host] – In my case, this points to our eclipse mosquitto instance in the Kubernetes cluster.
  • Port: [MQTT Broker Port] – In my case, this ports to the expose NodePort for eclipse moquitto.

Driver Configuration

Other than general MQTT configuration, which will need to point to the eclipse-mosquitto instance, you may or may not need to update the IncomingTopic and ResponseTopic. The example we use in the tutorial, uses the default configuration values provided within the example of the Device Service.

  • IncomingTopic: DataTopic – topic in which our device will push temperature value to.
  • ResponseTopic: ResponseTopic – topic in which we will publish the response from the command invocation.

Finalized configuration.toml

IP Addresses have been redacted and should be modified to better fit your scenario.

# Turning the log-level to DEBUG so that we can capture publish/subscribe actions
[Writable] LogLevel = ‘DEBUG’

# Configuration for the device MQTT service:
# Set the Host my machine’s IP address
# Leaving the defaults for the remaining configurations.
[Service] BootTimeout = 30000
CheckInterval = ’10s’
ClientMonitor = 15000
Host = ‘localhost’
Port = 49982
Protocol = ‘http’
StartupMsg = ‘device mqtt started’
Timeout = 5000
ConnectRetries = 10
Labels = [] EnableAsyncReadings = true
AsyncBufferSize = 16

# We are not using the Registry within this example
[Registry] Host = ‘localhost’
Port = 8500
Type = ‘consul’

# Using defaults
[Logging] EnableRemote = false
File = ”

# Configure clients for the other microservices:
# Pointing at the EdgeX Deployments in the VMWare One Cloud.
[Clients] [Clients.Data] Protocol = ‘http’
Host = ‘k8s.cluster’
Port = 48080

[Clients.Metadata] Protocol = ‘http’
Host = ‘k8s.cluster’
Port = 48081

[Clients.Logging] Protocol = ‘http’
Host = ‘k8s.cluster’
Port = 48061

# Configuration for the device:
# Ensure that ProfilesDir is pointing to the directory which the device profile configrations reside.
[Device] DataTransform = true
InitCmd = ”
InitCmdArgs = ”
MaxCmdOps = 128
MaxCmdValueLen = 256
RemoveCmd = ”
RemoveCmdArgs = ”
ProfilesDir = ‘./res/lf-edge’
UpdateLastConnected = false

# Pre-define Devices:
# Temperature Sensor and AC Fan devices.
# Configured to point at MQTT broker in the Cloud.
# Using CommandTopic as the topic which will handle actuating the devices.
# Configure automated events on the temperature Device Resource
[[DeviceList]] Name = ‘Temperature Sensor’
Profile = ‘TemperatureSensorProfile’
Description = ‘Simulated MQTT Temperature Sensor device’
Labels = [ ‘MQTT’, ‘Temperature’, ‘Sensor’ ] [DeviceList.Protocols] [DeviceList.Protocols.mqtt] Schema = ‘tcp’
Host = ‘k8s.cluster’
Port = ‘1883’
ClientId = ‘CommandPublisher’
User = ‘admin’
Password = ‘public’
Topic = ‘CommandTopic’
[[DeviceList.AutoEvents]] Frequency = ’20s’
OnChange = false
Resource = ‘temperature’

# Driver configs:
# DataTopic is the topic the Device Service will use to provide to Core Data.
# Reference MQTT Broker in the Cloud.
# ResponseTopic is the topic which the Device scripts will use to communicated responses on command invocations.
[Driver] IncomingSchema = ‘tcp’
IncomingHost = ‘k8s.cluster’
IncomingPort = ‘1883’
IncomingUser = ‘admin’
IncomingPassword = ‘public’
IncomingQos = ‘0’
IncomingKeepAlive = ‘3600’
IncomingClientId = ‘IncomingDataSubscriber’
IncomingTopic = ‘DataTopic’
ResponseSchema = ‘tcp’
ResponseHost = ‘k8s.cluster’
ResponsePort = ‘1883’
ResponseUser = ‘admin’
ResponsePassword = ‘public’
ResponseQos = ‘0’
ResponseKeepAlive = ‘3600’
ResponseClientId = ‘CommandResponseSubscriber’
ResponseTopic = ‘ResponseTopic’
ConnEstablishingRetry = ’10’
ConnRetryWaitTime = ‘5’

Router Port-Forwarding

Given a scenario where EdgeX Foundry is deployed in the cloud, and our devices are on a local network, one option is to leverage port-forwarding our your router.

In my scenario, EdgeX Foundry exists in VMWare’s One Cloud while my MQTT Device Service and device simulations reside on my local home network. While it is not recommended for this setup on a home network (for security purposes), I am going to use my home network and configure port-forwarding on my router to demonstrate this flow for similar environments. This will allow me to register my MQTT Device Service within EdgeX Foundry using my public IP address.

With the help of port-forwarding, I can configure my router to forward all requests to http://[PUBLIC IP]:49982 to the machine which is running the MQTT Device Service on port 49982.

The flow demonstrated in Figure B assumes ingress/egress routing supports communication between both entities.

Actuating MQTT Devices from the cloud

Before diving in, here are the host and port configurations I will use to access EdgeX:

  • edgex-core-data: k8s.cluster:30800
  • edgex-core-metadata: k8s.cluster:30801
  • edgex-core-command: k8s.cluster:30802

Earlier, we’ve configured MQTT Device Service to run on localhost on a machine within a local network. If your setup is similar to mine, this will not be accessible from a cloud environment. Fortunately, we can use core-metadata’s API to modify the URLs at which the Device Service can be accessed from the cloud. Since device-mqtt-go is still running on localhost with port-forwarding configured, the Device Service can be accessed by EdgeX in the cloud.

Let’s get the Device Service’s Addressable details in effort to capture this device information we will use to update some routing information.

# Invoking core-metadata

curl –location –request GET ‘k8s.cluster:30801/api/v1/addressable’

This will yield a response similar to:

[
{
“created”: 1594771598214,
“modified”: 1594771598214,
“origin”: 1594771598226,
“id”: “0da6eda1-fad9-41b6-a1c3-c50aab4679f8”,
“name”: “edgex-device-mqtt”,
“protocol”: “HTTP”,
“method”: “POST”,
“address”: “localhost”,
“port”: 49982,
“path”: “/api/v1/callback”,
“baseURL”: “http://localhost:49982”,
“url”: “http://localhost:49982/api/v1/callback”
}
]

Now lets use the previous response body and update the following fields to reference our network’s public IP: – address – baseUrl – url

Note that [PUBLIC IP] is used in place of your the IP address that you will use when routing to your network

# Invoking core-metadata

curl –location –request PUT ‘k8s.cluster:30801/api/v1/addressable’ \
–header ‘Content-Type: application/json’ \
–data-raw ‘{
“id”: “0da6eda1-fad9-41b6-a1c3-c50aab4679f8”,
“name”: “edgex-device-mqtt”,
“protocol”: “HTTP”,
“method”: “POST”,
“address”: “[PUBLIC IP]”,
“port”: 49982,
“path”: “/api/v1/callback”,
“baseURL”: “http://[PUBLIC IP]:49982”,
“url”: “http://[PUBLIC IP]:49982/api/v1/callback”
}’

At this point, the Device Service is routable from the cloud. Next, let’s get the TemperatureSensor device ID:

# Invoking core-command

curl –location –request GET ‘k8s.cluster:30802/api/v1/device/name/TemperatureSensor’

This will result in a response like this:

{
“id”: “7af6bad7-7c4f-408b-9a62-eb909e0aad4f”,
“name”: “TemperatureSensor”,
“adminState”: “UNLOCKED”,
“operatingState”: “ENABLED”,
“labels”: [
“MQTT”,
“Temperature”,
“Sensor”
],
“commands”: [
{
“created”: 1594771641016,
“modified”: 1594771641016,
“id”: “118cb3c7-3c1b-4088-bd88-7c27d304aba9”,
“name”: “temperature”,
“get”: {
“path”: “/api/v1/device/{deviceId}/temperature”,
“responses”: [
{
“code”: “200”,
“description”: “Get the temperature”,
“expectedValues”: [
“temperature”
] },
{
“code”: “500”,
“description”: “internal server error”
}
],
“url”: “http://localhost:48082/api/v1/device/7af6bad7-7c4f-408b-9a62-eb909e0aad4f/command/118cb3c7-3c1b-4088-bd88-7c27d304aba9”
},
“put”: {
“url”: “http://localhost:48082/api/v1/device/7af6bad7-7c4f-408b-9a62-eb909e0aad4f/command/118cb3c7-3c1b-4088-bd88-7c27d304aba9”
}
}
] }

We can extract the get command from the response for TemperatureSensor. This URL can be used to get the temperature value from the device itself.

Something worth noting is that the URL generated within the response above, uses the configured Host and Port values from core-command. Depending on your setup, you may need to invoke a different URL to access core-command. In my particular instance, I am exposing core-command via NodePort Service type. This means that core-command is accessible only through a port range allowed by Kubernetes. The port assigned to core-command is not the same as the port used within the cluster. With a load-balancer, ingress, or some proper network configuration, it could certainly be set up in such that the internal DNS names can be resolved.

# Invoking core-command

curl –location –request GET ‘http://k8s.cluster:30802/api/v1/device/7af6bad7-7c4f-408b-9a62-eb909e0aad4f/command/118cb3c7-3c1b-4088-bd88-7c27d304aba9’

response

{
“device”: “TemperatureSensor”,
“origin”: 1594773351741563527,
“readings”: [
{
“origin”: 1594773351741189868,
“device”: “TemperatureSensor”,
“name”: “temperature”,
“value”: “119.017532”,
“valueType”: “String”
}
],
“EncodedEvent”: null
}

We have now demonstrated bi-directional communication between devices on a local network and EdgeX Foundry in the cloud. While this is a simple demonstration, this flow can enable provisioning edge-device clusters which interact with EdgeX Foundry quickly. With an EdgeX instance deployed in the cloud, this flow (depending on networking), is portable enough to experiment with the different protocols EdgeX Foundry supports.

This tutorial is a start of what can be accomplished with EdgeX Foundry. We’ve walked through a simple flow where we can establish bi-directional communication between edge devices and EdgeX Foundry in the cloud. With all the supported protocols, it is rather simple to get EdgeX up and running with the the Device Service of your choice.

Visit the EdgeX Foundry website for more information or join Slack to ask questions and engage with community members. If you are not already a member of the community, it is really easy to join. Simply visit the wiki page and/or check out the EdgeX Foundry Git Hub.

Calling all innovators!! You’re invited to compete in the EdgeX Foundry Challenge Shanghai 2020

By Blog, EdgeX Foundry

Written by Intel’s Ying J Lu, EdgeX Foundry Community Member

On July 3, the EdgeX Foundry Challenge Shanghai 2020 was successfully kicked off as a joint effort among EdgeX community members Intel, VMware, Dell Technologies, HP, Thundersoft, IOTech, Tencent, and Shanghai startup incubator Innospace.

Leaders from the Linux Foundation and LF Edge welcomed community members for a virtual kick-off of the EdgeX Challenge, aimed at building a learning platform for EdgeX Foundry ecosystem partners in China. This initiative enables development of open, scaled industry solutions. It brings together participants with in-depth industry knowledge and developers to identify use cases to solve top industry problems and build demonstrations that move toward an integrated commercial solution. So far, more than 16K people have tuned in to view the challenge kick-off.

Why is edge important?

In today’s data-driven landscape, the Internet of Things provides a number of sensors and terminal devices with a variety of protocols, creating complexity to integrate them into a unified platform. To address the increasing demand to introduce new workloads such as artificial intelligence at the edge, fuse data on customers’ premises and the interwork with different cloud service providers,  this and future EdgeX challenges will help to accelerate a community of practice for architecting modern solutions.

As the world’s learning open edge computing framework, EdgeX Foundry is well positioned to address the edge opportunities as well as its complexity. “Intel is committed to support development of EdgeX Foundry”, says Wei Chen, Vice President of the Intel IOT Group, “including active code contribution, strong evangelism, and active development within the open source EdgeX ecosystem. Intel is also supporting the EdgeX China Project, which specifically supports the EdgeX Foundry community in China.”

Intel has also been actively collaborating in the greater open edge ecosystem by introducing OpenVINOTM toolkits to accelerate AI at the edge, growing the Open Retail Initiative to create and drive adoption of data rich solutions in retail leveraging open source ingredients, and launching Edge reference implementations for Retail and Industrial use cases available at the Intel’s Edge Software Hub. All of these efforts focus on nurturing a healthy and strong edge compute ecosystem.

The Challenge Highlights

The EdgeX Challenge Shanghai is co-hosted by the Linux Foundation and Science & Technology Commission of Shanghai Municipality (STCSM). The goal is to create a space for collaboration, using state-of-the-art technology frameworks, such as EdgeX Foundry which is part of the Linux Foundation, to address business challenges related to commerce and industrial verticals.

There are two major tracks covering the following industries:

  • Commerce: Retail, banking, hospitality, education, smart home, healthcare, cities and campus
  • Industrial: Manufacturing, power, oil and gas, utilities

The Challenge contest consists of two rounds, before winners are selected. In the preliminary round, all participants are required to submit an ideation document to describe how EdgeX-based technical frameworks are used in conjunction with a relevant industry use case. Judges will then select ten use cases to compete in the final round. Each team must demonstrate and showcase their solution which will consist of an interview by the judge’s review committee. Three levels of prizes will be awarded to winning teams.

Challenge Timeline:

Join the Competition

Registration for the EdgeX Challenge Shanghai is open until July 20, 2020. All are welcome—system integrators (SIs), independent solution vendors (ISVs), original equipment manufacturers (OEM, developers, universities and research institutes—to join the challenge.

Register here by July 20, to join the EdgeX Challenge Shanghai.

To see the kickoff from July 3, visit the EdgeX Challenge Shanghai 2020 video challenge here.

Collaborate with the EdgeX Foundry community

EdgeX Foundry – Delivering choice, flexibility, and collaboration at the IOT Edge

By Blog, EdgeX Foundry

Written by Keith Steele, CEO of IOTech Systems

After 3 years, I step down as the chair of the EdgeX Foundry Technical Steering Committee later this month. When I took on the role, I believed Open Software Platforms were fundamental to the success of edge computing and supported that view by backing EdgeX Foundry and starting IOTech. Today, with more than 6 million downloads, and many customer deployments later, both EdgeX and IOTech are strong. As we enter the next phase, here are my reflections and thoughts about where we go next…

From little acorns…..EdgeX Foundry

EdgeX Foundry was launched at Hannover Messe in April 2017 as an open source project hosted by The Linux Foundation. With this as a backdrop, we held our first project meeting in Boston in June 2017 and companies were invited to participate in creating EdgeX as an industrial IoT global edge software platform standard.

There were about 60 of us who showed up in person from all around the world, and even more joined by phone. We set our vision at this meeting and formed the EdgeX Technical Steering Committee to deliver that vision.

For the first 2 years, the team set about turning what was effectively a platform demonstrator project into a deployable product, including a complete rewrite of the code from Java into GO and C to reduce footprint and improve latency, critical requirements for edge-based systems. This culminated in the Edinburgh release in June 2019, when we announced to the world, we were satisfied the quality was sufficient to support deployed systems. Up to that point we had promoted EdgeX for use for pilot only implementations.

The Fundamentals

There are several fundamental technical and business tenets we set out so solve with EdgeX Foundry:

Open vs. Proprietary – The idea behind EdgeX is to maximize choice so users do not have to lock themselves into proprietary technologies that, by design, limit choice. Given the implicit heterogeneity at the edge, ‘open’ at a minimum means the EdgeX platform must be silicon, hardware, operating system, software application and cloud agnostic.

Secure, Pluggable and Extensible Software Architecture – To offer choice and flexibility to our users the EdgeX team chose a modern, distributed, microservices based software architecture, which we believe supports the inherent complexities at the edge.

Edge Software Application ‘Plug and Play’ – EdgeX provides a standard open framework around which an ecosystem can emerge. It facilitates interoperable plug-and-play software applications and value add services providing users with real choice, rather than having to deal with siloed applications, which may potentially require huge system integration efforts to deliver and end to end IoT Edge solution.

Time-Critical Performance and Scalability – Edge applications need access to ‘real-time’ data e.g. millisecond or even microsecond response times, often with absolute real-time predictability requirements. Access to real time data is a fundamental differentiator between the edge and cloud computing worlds. EdgeX addresses round trip response time requirements in the milliseconds with target operating environments are server and gateway class computers running standard Windows or Linux operating systems.

The EdgeX project decided to leave it to the ecosystem to address Time-Critical edge systems, which require ultra-low footprint, microsecond performance and even hard real time predictability.  IOTech, like many other EdgeX Foundry contributors, has created a commercial solution for EdgeX Foundry – called Edge XRT. It is important real-time requirements are understood in full, as decisions taken can significantly impact success or failure of edge projects.

Connectivity and Interoperability- A major difference between the edge and cloud is inherent heterogeneity and complexity at the edge.  The edge is where the IT computer meets the OT ‘thing’ and there is a multitude of ‘connectivity’ protocols at or close to real time. EdgeX provides reference implementations of some key protocols along with SDKs to readily allow users to add new protocols. The commercial ecosystem also provides many additional connectors, making connectivity a configuration versus a programming task. Likewise, Northbound there are multiple cloud and other IT endpoints and EdgeX provides flexible connectivity to and from these different environments. EdgeX is cloud agnostic coming with many standard integrations.

LF Edge launches

Equally as important as the technical deliverables for an open source project is the ecosystem of companies which support it. The EdgeX ecosystem was greatly enhanced in January 2019 when EdgeX Foundry became one of five founding projects in LF Edge, an umbrella organization created by The Linux Foundation that “aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system.” LF Edge’s objective is to bring together complementary open source edge technologies.

As one of the Stage 3 projects under LF Edge, EdgeX Foundry momentum increased with additional global collaboration. The increased amplification and support across LF Edge projects, community and members has helped turn EdgeX into a high velocity project.

Delivering  complementary products and solutions

EdgeX is a framework around which a global ecosystem of vendors can emerge to offer complementary edge products and services including commercial support, training and customer pilot programs, which add value to the baseline product.

Here are a few examples:

EdgeX in Retail

A great example of how companies deliver solutions around EdgeX is Intel’s Open Retail Initiative (ORI), a collaborative effort led by Intel and top technology companies. The goal of ORI is to accelerate the scalable deployment of data-rich solutions optimized for in-store retail, from the edge to the cloud. ORI leverages EdgeX, alongside vendor proprietary solutions, to deliver use cases based on ecosystem components (or “ingredients”) having a common, open framework EdgeX, which enables an ecosystem of interchangeable components and accessible data—a future-ready platform for innovation. Members of the ORI community include some of the industry’s leading device makers, independent software vendors, system integrators, and consultants.

Remote monitoring telemetry of energy supply networks

In another application, one of the world’s leading energy infrastructure operators collaborated with a Global SI on several Industrial IoT projects aimed at digitalizing its main assets and energy distribution processes.

The SI helped the customer to implement a real-time monitoring system for several gas compression and storage injection stations, using the EdgeX platform for data collection and aggregation, and the at-the-edge calculation of relevant performance metrics.

This application provides the customer with a real-time overview of station operational conditions, and an historical view of data trends to more deeply understand the critical information needed by future analytics to improve Operational & Management activities

The business value to the client included: maintenance activities improved by real-time remote monitoring; data from different machines analyzed on the edge and gathered in a central platform, remote monitoring enabling new users’ education and system knowledge.

Underlying software infrastructure for an AI Edge Platform

Accenture, the world’s largest Systems Integrator has based the Edge offering for its Applied Intelligence Platform+ (AIP+) on EdgeX. AIP+ is marketed globally, and includes a collection of modular, pre-integrated AI services and capabilities to accelerate and scale new outcomes. The AIP+ Edge Agent includes tools and software to support the deployment and management of machine-learning and analytics-based intelligence on devices.

Accenture was particularly attracted by the EdgeX open ecosystem: open-source and container-based pedigree, no lock-in (cloud/ chipset/ OS agnostic), and the potential of strategic partnerships to complement Accenture’s AIP+ focus.

IOTech’s Contribution to the Ecosystem

In each of the above situations the participating companies all benefited from the choice, flexibility, and the collaboration EdgeX enables at the IoT edge. All of the above examples also exploited IOTech’s contributions to the EdgeX ecosystem using our hardened, extended and fully supported licensed version of EdgeX, Edge Xpert.

As mentioned earlier IOTech is also delivering a time critical version of the platform named XRT, and an extensive range of industrial grade north and southbound connectors.

The scale, complexity, and variability of systems at the edge means the management of edge-based systems can be challenging. Today’s enterprise management and deployment systems work very well in enterprise / cloud environments but are not well suited to edge deployments.  Resource constraints, intermittent connectivity of the edge, and the large variety of OT protocols are just some of the issues that present additional challenges to managing and deploying edge solutions. Also, local security constraints may mean that access to and from the cloud is severely curtailed or not permitted, so cloud-based management will not be possible.

What’s Next

The project has 170 code contributors. EdgeX Foundry just completed its sixth release (Geneva), and in just twelve months since the first official ‘ready for primetime’ V1 release back in June 2019, has achieved millions of container downloads world-wide.

The EdgeX Foundry project goes is strong with huge momentum behind its V1 Release.  We are now moving forward with EdgeX 2.0, which will see increased focus on outreach, including greater attention given to EdgeX users as well as developers.  Indeed, this is where I will be concentrating my efforts going forward after stepping down as TSC Chair in June.

I am very proud of what the team has collectively achieved with EdgeX in 3 years from our first meeting in Boston. We have taken EdgeX from a Dell CTO led project to be the premier open edge software platform across the world.

From a personal standpoint, I would offer these key observations and takeaways as to why EdgeX has been successful:

  • Create a real problem to solve that can unify a community around solving it and provide real business value to those who contribute.
  • Collaboration is key with consistency of participation, maintaining key technical community leadership and contributors for at least a couple of years is very important. Projects like EdgeX take time, the problem is complex and there is no short cut to delivering quality.
  • Do not boil the ocean, as the diversity of your project increases look for alignment and complementary projects that can move your forward. EdgeX security is a prime example of this.
  • Understand your objectives and design the project accordingly, our objective in EdgeX was to grow a global standard. We took a decision in the early days to focus on quality, testing and API consistency to ensure what we delivered was of product quality, this has ensured we have a supportable and evolvable product that users can rely on.
  • Set the expectations of your target users. The team worked hard to make the 4th release (Edinburgh release) ‘deployment ready’ and, once we announced this, our downloads increased and we’re now heading to mass adoption on a global scale.

Most importantly, EdgeX Foundry has been a great team effort and a lot of fun! I am very much looking forward to the next phase of success.

Some Closing Thoughts

The full promise of IoT will be achieved when you combine the power of cloud and edge computing: delivering real value that allows businesses to analyze and act on their data with incredible agility and precision, giving them a critical advantage against their competitors.

The key challenges at the edge related to latency, network bandwidth, reliability, security, and OT heterogeneity cannot be addressed in cloud-only models – the edge needs its own answers.

EdgeX Foundry and the LF Edge ecosystem offer an answer, maximizing user choice and flexibility and enabling effective collaboration across multiple vertical markets at the edge helping to power the next wave of business transformation.

To learn more, please visit the EdgeX website and LF Edge website and get involved!

 

New Training Course Aims to Make it Easy to Get Started with EdgeX Foundry

By Announcement, EdgeX Foundry, Training

Course explains what EdgeX Foundry is, how it works, how to use it in your edge solutions, leveraging the support of LF Edge’s large ecosystem 

SAN FRANCISCO, July 1, 2020 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced the availability of a new training course, LFD213 – Getting Started with EdgeX Foundry.

LFD213, was developed in conjunction with LF Edge, an umbrella organization under The Linux Foundation that aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system. The course is designed for IoT and/or edge software engineers, system administrators, and operation technology technicians that want to assemble an edge solution.

The course covers how EdgeX Foundry is architected, how to download and run it, and how to configure and extend the EdgeX framework when needed. The four chapters of the course, which take approximately 15 hours to complete, provide a basic overview, a discussion of device services, which connect physical sensors and devices to the rest of platform, application services, how to send data from EdgeX to enterprise applications, cloud systems, external databases, or even analytics packages, and more.

Hands-on labs enable students to get and run EdgeX and play with some of its important APIs, as well as create a simple service (either device or application service) and integrate it into the rest of EdgeX.

EdgeX Foundry is an open-source, vendor-neutral, hardware- and OS-agnostic IoT/edge computing software platform that is a Stage 3 (Impact) project under LF Edge. In the simplest terms, it is edge middleware that sits between operational technology, physical sensing “things” and information technology systems. It facilitates getting sensor data from any “thing” protocol to any enterprise application, cloud system or on-premise database. At the same time, the EdgeX platform offers local/edge analytics to be able to offer low latency decision making at the edge to actuate back down onto sensors and devices. Its microservice architecture and open APIs allow for 3rd parties to provide their own replacement or augmenting components and add additional value to the platform. In short, EdgeX Foundry provides the means to build edge solutions more quickly and leverage the support of a large ecosystem of companies that participate in edge computing.

“EdgeX Foundry is on a phenomenal growth trajectory with multiple releases and millions of container downloads,” said Jim White, EdgeX Foundry Chair of the Technical Steering Committee and CTO of IOTech Systems.  “Given the scale of the adopting community and ecosystem, it is critical that there is proper training available to allow new adopters and prospective users to learn how to get started. The new training, created by the architects of EdgeX Foundry and managed by The Linux Foundation, will allow developers exploring EdgeX a faster and better path to understand and work with EdgeX while also accelerating our project’s adoption at scale.”

The course is available to begin immediately. The $299 course fee provides unlimited access to the course for one year including all content and labs. Interested individuals may enroll here.

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

# # #

EdgeX Foundry Kubernetes Installation

By Blog, EdgeX Foundry

Written by Jason Bonafide, EdgeX Foundry Contributor and Principal Software Engineer at Dell Technologies

In an ever-growing world of connected devices, there is plenty of opportunity in edge computing. While devices are getting smaller and smarter, there is always a need to share data. With that, I have just the platform for you!

EdgeX Foundry is a vendor-neutral open source project hosted by LF Edge building a common open-framework for IoT edge computing. EdgeX Foundry offers a set of interoperable plug-and-play components which aim to satisfy IoT solutions of all variations.

The goal of this blog is to walk through techniques which can be used in deploying EdgeX Foundry to a Kubernetes cluster. Establishing a foundation for deploying EdgeX in Kubernetes is the main takeaway from this tutorial.

Tools and technologies used

Why Deploy EdgeX to a Kubernetes cluster?

Kubernetes provides the following feature set:

  • Service Discovery and load balancing
  • Storage orchestration
  • Automated roll-outs and rollbacks
  • Automatic bin packing
  • Self-healing
  • Secret and configuration management

EdgeX Foundry is built on micro-service architecture. The micro-service architecture is powerful, but it can make deploying and managing an application more complex because of all the components. Kubernetes makes deploying micro-service applications more manageable.

Glossary

Kubernetes

  • Affinity: Act of constraining a Pod to a particular Node.
  • ConfigMap: An API object used to store non-confidential data in key-values pairs.
  • Deployment: Provides declarative updates for Pods and ReplicaSets.
  • Ingress: Exposes HTTP and HTTPS routes from outside the cluster to Services within the cluster.
  • kubelet: Primary “node agent” that runs on each Node. It works in terms of a PodSpec.
  • LivenessProbe: The means used in a Kubernetes Deployment to check that a Container is still working and to determine whether or not it needs to be restarted.
  • Node: Virtual or physical machine in which Pods are run.
  • PersistentVolume: A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using StorageClasses.
  • PersistentVolumeClaim: A request for storage by a user.
  • Pod: The smallest deployable unit of computing that can be created and managed in Kubernetes.
  • PodSpec: A YAML or JSON object that describes a Pod.
  • ReadinessProbe: The means used in a Kubernetes Deployment to check when a Container is ready to start accepting traffic.
  • Secret: An object that contains a small amount of sensitive data such as a password, a token or a key.
  • Service: An abstract way to expose an application running on a set of Pods as a network service.
  • StartupProbe: The means used in a Kubernetes Deployment to check whether or not the Container’s application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don’t interfere with the application startup.
  • StorageClass: Provides a way for administrators to describe the “classes” of storage they offer.
  • Volume: A directory, possibly containing some data which can be accessed by a Container.
  • Volume Mount: A property for a Container in which a Volume is bound the Container.

Helm

  • Chart: An artifact which contains to a collection of Kubernetes resource files.
  • Named Template: A template which has an identifying name. Named-templates are also referred to as “partials”. Named-templates are similar to that of a programming language’s function which can be used to re-use code (or in this case YAML configuration).
  • Template: A file that can hold placeholders {{}} and are interpolated by specified values
  • yaml: A configuration file within Helm which enables abstraction of configurable items which can be applied to templates.

Setting up manifests directory

Create the directory structure below on your machine. The folders will be used and populated throughout this tutorial.

project-root/
edgex/
templates/
edgex-redis/
edgex-core-metadata/
edgex-core-data/
edgex-core-command/

Before we create definition files

Kubernetes provides a recommended set of labels. These labels provide a grouping mechanism which facilitate management of Kubernetes resources which are bound to an application. Below is Kubernetes’ recommended set of labels:

app.kubernetes.io/name: <application name>
app.kubernetes.io/instance: <installation>
app.kubernetes.io/version: <application version>
app.kubernetes.io/component: <application component>
app.kubernetes.io/part-of: <organization>
app.kubernetes.io/managed-by: <orchestrator>

A concrete example of this would be:

app.kubernetes.io/name: edgex-core-metadata
app.kubernetes.io/instance: edgex
app.kubernetes.io/version: 1.2.1
app.kubernetes.io/component: api
app.kubernetes.io/part-of: edgex-foundry
app.kubernetes.io/managed-by: Kubernetes

With the above label structure, and kubectl’s support of filtering resources by labels, we’ve created enough labels which give us plenty of flexibility when searching for specific resources. An example of this would look like:

$ kubectl get pod -l app.kubernetes.io/name=edgex-core-metadata

In a cluster with many applications, the above command will result in selecting only edgex-core-metadata pods.

On to our first application – edgex-redis

EdgeX Foundry supports Redis as a persistent datastore. Due to the fact that Containers are ephemeral, data created within a Container will live only as long as the Container. In order to keep data around past the life its Container, we will need to use a PersistentVolume.

Lets say that we want to create a PersistentVolume with the following in mind:

  • Our cluster contains a StorageClass named hostpath.
  • Our use-case requires 10Gi of storage (not to be confused with GB – Kubernetes has its own Resource Model).
  • Redis data needs to be stored on a cluster node’s file-system at /mnt/redis-volume. It is worth noting that hostPath storage plugin is not recommended in production. If your cluster contains multiple nodes, you will need to ensure that the edgex-redis Pod is scheduled on the same node. This is to ensure that edgex-redis references the same hostPath storage each time the Pod is scheduled. Please refer to Assigning Pods to Nodes documentation for more information.
  • We anticipate many nodes having Read and Write access to the PersistentVolume.

With the above requirements, our PersistentVolume definition in templates/edgex-redis/pv.yaml should be updated to look like this.

Although the PersistentVolume has not been created yet, we’ve defined a resource that will make the storage we defined in the PersistentVolume definition available for binding. Next, we will need to create a resource that will assign a PersistentVolume to an application. This is accomplished using a PersistentVolumeClaim.

The pattern used in this tutorial establishes a one-to-one relationship between application and a PersistentVolume. That means, for each PersistentVolume, there will exist a PersistentVolumeClaim for an application. With that in mind, our claim for storage capacity, access modes, and StorageClass should match the PersistentVolume we defined earlier.

Lets go over the requirements for our storage use-case:

  • 10Gi storage.
  • Read and Write access by many nodes.
  • A StorageClass named hostpath exists in our cluster.

Given the above requirements, the PersistentVolumeClaim definition file at templates/edgex-redis/pvc.yaml should be updated to look like this.

Now that the PersistentVolume and PersistentVolumeClaim have been defined, lets move on to the Deployment.

Similar to what was done with the PersistentVolume and PersistentVolumeClaim, lets list things that describe the Redis application:

  • For simplicity sake, lets say we only create 1 instance (replica).
  • When a new version is rolled out, we want to kill all of the old pods before bringing up new pods. This is referred to as a Recreate deployment strategy.
  • The Deployment consists of a single process (Container).
  • The Container image will come from Dockerhub’s redis image of latest
  • The Container will listen to connections on port 6379.
  • The application will write data to /var/lib/redis. The Container’s data directory will be mounted to the PersistentVolume via the PersistentVolumeClaim named edgex-redis which we created earlier. The Volume mapped to the PersistentVolumeClaim will be named redis-data and can be mounted as Volume for the Container.
  • The application is in a Started state when a connection can be successfully established over TCP on port 6379. This check will be tried every 10 On the first success, the Container will be in a Started state, however, on the 5th failure to obtain a connection, the Container will be killed. When this StartupProbe is enabled, LivenessProbe and ReadinessProbe are disabled until StartupProbe succeeds.
  • Every 30 seconds, only after a 15 second delay, the Deployment will ensure that the Container is alive by establishing a connection over TCP on port 6379. On the first success, the Container will be in a Running state, however, on 3 failures, the Container will be restarted.
  • Every 30 seconds, only after a 15 second delay, the Deployment will try to determine if the Container is ready to accept traffic. Over TCP, the Deployment will attempt to establish a connection on port 6379. On 3 failures, the pod is removed from Service load balancers.

Given the above requirements, we can define our Deployment in templates/edgex-redis/deployment.yaml should be updated to look like this.

Lastly, for edgex-redis, we will need to establish network access to our Pod within the Kubernetes cluster. This is accomplished by defining a Service.

As for our Service requirements:

  • selector should only match the labels defined in the edgex-redisDeployment’sPodSpec.
  • Map external port 6379 to Container port 6379 with a name of port-6739. Each port requires a name.

On to the next application – edgex-core-metadata

EdgeX application supports the concept of externalized configuration. This is a neat feature enabling the platform’s portability. For our Deployment, we will define our configuration as a Secret. Normally configuration would be defined in a ConfigMap, however, since Redis credentials reside in our configuration file, we will stash the entire configuration file in a Secret.

We are going to leverage the default application configuration and make just a few just a few modifications:

  • Core Metadata Service Host property has been updated to listen on 0.0.0 which ensures that the Container is listening on all network interfaces.
  • Core Data Service Host property has been updated to edgex-core-data Later on when edgex-core-data is installed, a Service will expose edgex-core-data as the hostname of edgex-core-data.
  • Database Host property has been updated to edgex-redis Service

Feel free to refer to the reference project configuration files here.

Lets create the secret by performing the following steps:

  • Download https://github.com/jbonafide623/edgex-lf-k8s/blob/master/secrets/edgex-core-metadata-secret or create your own.
  • Execute $ kubectl create secret generic edgex-core-metadata –from-file=configuration.toml=edgex-core-metadata-secret (where edgex-core-metadata-secret points to the file downloaded in the previous step).

Now for the edgex-core-metadata Deployment. Lets list out some of the requirements:

  • We will create only 1 instance (replica).
  • When a new version is rolled out, we want to kill all of the old pods before bringing up new pods. This is referred to as a Recreate deployment strategy.
  • The Deployment consists of a single process (Container).
  • The Container image will come from Dockerhub’s edgexfoundry/docker-core-metadata-go image of 2.1 tag.
  • Override the Dockerfile’s Entrypoint so that –confdir points to /config.
  • Disable security via EDGEX_SECURITY_STORE environment variable. This can be done by setting the flag to “false”.
  • The Container will listen to HTTP requests on port 48081.
  • The application is in a Started state when a n HTTP GET request to /api/v1/ping results in a 200 response. This check will be tried every 10 On the first success, the Container will be in a Started state, however, on the 5th failure to obtain a connection, the Container will be killed. When this StartupProbe is enabled, LivenessProbe and ReadinessProbe are disabled until StartupProbe succeeds.
  • Every 30 seconds, only after a 15 second delay, the Deployment will ensure that the Container is alive by sending an HTTP GET request to /api/v1/ping. On the first success, the Container will be in a Running state, however, on 3 failures, the Container will be restarted.
  • Every 30 seconds, only after a 15 second delay, the Deployment will try to determine if the Container is ready to accept traffic. Over TCP, the Deployment will attempt to send an HTTP GET request to /api/v1/ping. On 3 failures, the pod is removed from Service load balancers.
  • Establish a limit on cpu usage of 1 and request a starting allocation of 5 cpus.
  • Establish a limit on memory usage of 512Mi and request a starting allocation of 256Mi memory.
  • Mount the configuration Secret with name edgex-core-metadata to the Container’s path /config. Recall /config is the path that we supply as a –confdir override to the application’s image.

Given the above requirements, we can define our Deployment definition file at templates/edgex-core-metadata/deployment.yaml and it should look like this.

Lastly, lets expose the application so that it can be accessed from within and outside of the cluster. For our Service lets define the some requirements:

  • selector should only match the labels defined in the edgex-core-metadataDeployment’sPodSpec.
  • Map external port 48081 to Container port 48081 with a name of port-48081. Each port requires a name.
  • Expose the application outside of the cluster via NodePort type on port 30801

Given the above requires we can define our Service definition file at templates/edgex-core-metadata/service.yaml and it should look like this.

Incorporating Helm

The decision to include Helm in the container-orchestration stack is based on the following Helm features:

  • Helm Facilitates a single responsibility which is to manage Kubernetes resources.
  • Enables easy application installation and rollback.
  • Supports ordered creation of resources via hooks.
  • Provides access to installations of popular applications via Helm Hub.
  • Encourages code-reuse.

Each Helm chart contains values.yaml and Chart.yaml files. In the root of the project directory, lets go ahead and create these files by executing:

touch values.yaml
touch Chart.yaml

Chart.yaml contains information about the chart. With that in mind, lets add the following content to Chart.yaml:

apiVersion: v2
name: edgex
description: A Helm chart for Kubernetes

# A chart can be either an ‘application’ or a ‘library’ chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They’re included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
appVersion: 1.2.1

values.yaml allows you to create a YAML object which can be referenced in your chart’s template files.

Lets make use of what values.yaml can offer us.

For edgex-redis, lets list out some properties that might be beneficial to abstract out as a configurable option:

  • Application name: if you noticed, almost every resource uses the name edgex-redis. These resources can be accessed by other applications. For instance, edgex-core-metadata references the Service defined for edgex-redis. If we abstract the name out to yaml, the application name will only need to change in a single place (values.yaml).
  • Deployment strategy: If there is a particular environment where you are concerned with high-availability, you may want to leverage RollingUpdate In smaller environments, you may or may not care about a RollingUpdate strategy and would chose Recreate in effort to conserve computing resources.
  • Image name and tag: There exist scenarios where artifacts/dependencies are vetted and kept “in-house”. Scenarios like these include artifact/image repositories of their own. With that in mind, having the ability to switch the image registry during installation can be a huge benefit.
  • Port: The port at which the Container listens on is something that can easily be referenced in many places within a single chart. As you define various network components such as Ingresses, Services, and even the Container port, it would be nice to refer back to a single place.
  • Replicas: Depending on the environment’s resources, the number of replicas may change.
  • StorageClassName: There may exist a scenario where the StorageClass may completely vary from cluster to cluster or even within a single cluster.

Considering the above, we can define our edgex-redis configuration object like this:

edgex:
redis:
name: edgex-redis
deployment:
strategy: Recreate
image:
name: redis
tag: latest
port: 6379
replicas: 1
storageClassName: hostpath

We can apply the same pattern with a few adjustments for edgex-core-metadata:

edgex:
metadata:
name: edgex-core-metadata
deployment:
strategy: Recreate
image:
name: edgexfoundry/docker-core-metadata-go
tag: 1.2.1
port: 48081
replicas: 1
resources:
limits:
cpu: 1
memory: 512Mi
requests:
cpu: 0.5
memory: 256Mi

In the configuration object for edgex-core-metadata we added a resources object which allows us to adjust limits and requests during installation.

Remember earlier when we talked about recommended labels and how these labels apply to each of our resources? With Helm, we can create a named-template and include the named-template in each place where the labels are referenced.

Here, in the file templates/_labels.tpl, we are creating a named-template named edgex.labels. This named-template takes in two arguments a ctx (context) and AppName (application’s name).

{{/*
Define a standard set ouf resource labels.

params:
(context) ctx – Chart context (scope).
(string) AppName – Name of the application.
*/}}
{{ define “edgex.labels” }}
app.kubernetes.io/app: {{ .AppName }}
app.kubernetes.io/instance: {{ .ctx.Release.Name }}
app.kubernetes.io/version: {{ .ctx.Chart.AppVersion }}
app.kubernetes.io/component: api
app.kubernetes.io/part-of: edgex-foundry
app.kubernetes.io/managed-by: {{.ctx.Release.Service }}
helm.sh/chart: {{ .ctx.Chart.Name }}-{{ .ctx.Chart.Version | replace “+” “_” }}
{{ end }}

Now that we’ve defined configuration in values.yaml and created edgex.labels named template, lets apply them to a simple definition file in templates/edgex-redis/service.yaml.

apiVersion: v1
kind: Service
metadata:
name: {{ .Values.edgex.redis.name }}
labels:
{{- include “edgex.labels” (dict “ctx” . “AppName” $.Values.edgex.redis.name) | indent 4 }}
spec:
selector:
{{- include “edgex.labels” (dict “ctx” . “AppName” $.Values.edgex.redis.name) | indent 4 }}
ports:
– port: {{ .Values.edgex.redis.port }}
name: “port-{{ .Values.edgex.redis.port }}”

When the template is rendered, placeholder values will be interpolated by either properties specified in the values file or via –set flag. When helm install is executed with no -f flag, values.yaml in the root of chart is used by default. If we want to override values during installation, the property can be overridden using –set flag.

For an application as portable as EdgeX is, tying in configuration overrides can tremendously speed up deployments.

Finalizing the chart using a reference project

Up to this point, we have:

  • Created raw Kubernetes YAML files for edgex-redis and edgex-core-metadata.
  • Explained usage of yaml in Helm chart.
  • Adjusted edgex-redis Service definition file to reference Helm values and named-templates.

This, by no means is an end-to-end deployment. The patterns described above, gives you enough to apply to the remaining pieces you wish to include in your deployment. Here you can refer to the reference project which contains a finalized Helm chart responsible for Deploying: – edgex-redis – edgex-core-metadata – edgex-core-data – edgex-core-command

Following the pattern above, edgex-core-data and edgex-core-command will also require configuration files mounted as Secrets. You can create them by executing:

$ kubectl create secret edgex-core-data generic –from-file=configuration.toml=[path to edgex-core-data’s configuration.toml]

$ kubectl create secret edgex-core-command generic –from-file=configuration.toml=[path to edgex-core-command’s configuration.toml]

All of the Secrets can be accessed here in the reference project.

When your Helm chart is finalized, you can install it by executing:

# From the root of the project

$ helm install edgex –name-template edgex

In a sense, you get a free verification from the Container probes for each application. If your applications successfully start up and remain in a Running state, that is a good sign!

Each application can be accessed at [cluster IP]:[application’s node port]. For example, lets say the cluster IP is 127.0.0.1 and we want to access the /api/v1/ping endpoint of edgex-core-metadata, we can invoke the following curl request:

$ curl -i 127.0.0.1:30801/api/v1/ping

where nodePort 30801 is defined in edgex-core-metadata Service definition.

In closing

In this tutorial, we’ve only scratched the surface with respect to the potential that EdgeX Foundry has to offer. With the components we’ve deployed, the foundation is in place to continuously deploy EdgeX in Kubernetes clusters.

As a member of this amazing community I highly recommend checking out EdgeX Foundry Official documentation. From there you will have access to much more details about the platform.

As for next steps, I highly recommend connecting a Device Service to your EdgeX Core Services environment within Kubernetes. With the plug-and-play nature of the Device Sevice’s configuration, you can certainly have a device up and running within EdgeX intuitively.

This tutorial was built on a foundational project worked on at Dell. I would like to acknowledge Trevor Conn, Jeremy Phelps, Eric Cotter, and Michael Estrin at Dell for their contributions to the original project. I would also like to acknowledge the EdgeX Foundry community as a whole. With so many talented and amazing members, the EdgeX Foundry project is a great representation of the community that keeps it growing!

Visit the EdgeX Foundry website for more information or join Slack to ask questions and engage with community members. If you are not already a member of the community, it is really easy to join. Simply visit the wiki page and/or check out the EdgeX Foundry Git Hub.

EdgeX Foundry Welcomes New Contributors!

By Blog, EdgeX Foundry

Written by Aaron Williams, LF Edge Developer Advocate

The EdgeX Foundry community has been blessed with a large number of active contributors over the last three years, with many of those being with us since launch.  But all communities need new members and different perspectives to continue to improve and grow.  Yet, we know that it can be intimidating to post your first contribution to an open source project.  As such, we want to take a moment and thank the following people who posted their first contribution to EdgeX Foundry in Q1 of 2020.

Q1 New Contributors:

  • jluous
  • Aricg
  • jinlinGuan
  • kaisawind
  • venkata-subbareddyK
  • kurokobo
  • venkata-lakshmi-penna
  • worldmaomao
  • DaveZLB

You can find these contributors on github and see what other projects they are working on. We encourage our new contributors to keep up the great work and we look forward to their next contribution.  You are helping to improve and grow EdgeX and our community. Thank you for all your help!

If you would like to learn more about EdgeX Foundry,  the world’s first plug and play ecosystem-enabled open platform for the IoT Edge, visit the Getting Started page. You’ll learn more about the project and get  step-by-step directions about how to start your EdgeX journey.

EdgeX Foundry has global industry support LF Edge members and open source contributors. EdgeX offers the opportunity to collaborate on IoT solutions built using existing connectivity standards combined with their own proprietary innovations.

In fact, EdgeX Foundry recently announced the sixth release in its roadmap – the Geneva release offers simplified deployment, optimized analytics, secure connectivity for multiple devices and more robust security. Learn more about the Geneva release:

Visit the EdgeX Foundry website for more information or join our Slack to ask questions and engage with community members. If you are not already a member of our community, it is really easy to join.  Simply visit our wiki page and/or check out our Git Hub and help us get to the next 6 million and more downloads!

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.

EdgeX Foundry Hits Major Milestone with 5 Million+ Container Downloads and a New Release that Simplifies Deployment for AI, Data Analytics and Digital Transformation

By Announcement, EdgeX Foundry, LF Edge
  • EdgeX’s sixth release (Geneva) offers more scalable and secure solutions to move more data faster from multiple edge devices to cloud, enterprise and on-premises applications.
  • As one of LF Edge’s Stage 3 Projects, EdgeX Foundry is seeing increased community growth and adoption and deployments.
  • New LF Edge project Open Horizon is building an integration project that will demonstrate automated delivery and lifecycle management of EdgeX Foundry as a containerized application.

SAN FRANCISCOMay 21, 2020EdgeX Foundry, a project under the LF Edge umbrella organization within the Linux Foundation that aims to establish an open, interoperable framework for IoT edge computing independent of connectivity protocol, hardware, operating system, applications or cloud, today announced a major milestone of hitting 5 million container downloads and the availability of its “Geneva” release. This release offers more robust security, optimized analytics, and secure connectivity for multiple devices.

“EdgeX Foundry is committed to developing an open IoT platform for edge-related applications and shows no signs of slowing down the momentum,” said Arpit Joshipura, general manager, Networking, Edge and IoT, the Linux Foundation. “As one of the Stage 3 projects under LF Edge, EdgeX Foundry is a clear example of how member collaboration and diversity are the keys to creating an interoperable open source framework across IoT, Enterprise, Cloud and Telco Edge.”

Launched in April 2017, and now part of the LF Edge umbrella, EdgeX Foundry is an open source, loosely-coupled microservices framework that provides the choice to plug and play from a growing ecosystem of available third-party offerings or to augment proprietary innovations. With a focus on the IoT Edge, EdgeX simplifies the process to design, develop and deploy solutions across industrial, enterprise, and consumer applications.

Currently, there are more than 170 unique contributors to the project and EdgeX Foundry averages one million container downloads a month, with a total of 5 million reached last month, and rising.

“The massive volume of devices coming online represents a huge opportunity for innovation and is making edge computing a necessity,” said Keith Steele, EdgeX Foundry Chair of the Technical Steering Committee. “With at least 50% of data being stored, processed and analyzed at the edge we need an open, cloud-native edge ecosystem enabled by EdgeX to minimize reinvention and facilitate building and deploying distributed, interoperable applications from the edge to the cloud. In 3 short years, EdgeX has achieved incredible global momentum and is now being designed into IOT systems and product roadmaps.”

The Geneva Release

As the sixth release in the EdgeX Foundry roadmap, Geneva offers simplified deployment, optimized analytics, secure connectivity for multiple devices and more robust security. Key features include:

  • Automate on-boarding: simplify, scale and quicken connection of devices by allowing automatic provisioning of devices
  • Improved Performance: A new rules engine that is written in Go for faster performance, a smaller footprint and more memory
  • Connectivity: Improved bandwidth utilization and efficiency through use of new batch and send capabilities provided in the App Functions SDK
  • Secure Authentication: Store and use/authenticate secrets to connect with cloud providers
  • Testing: New integration and backward compatibility testing along with enhanced security and blackbox testing

EdgeX Foundry works closely with several of the other LF Edge projects such as Akraino Edge Stack and new project Open Horizon. During this release cycle, EdgeX was made to work under the Akraino Edge Lightweight IOT (ELIOT) Blueprint and tested under the Akraino Community Lab.

Launched last month, Open Horizon is a platform for managing the service software lifecycle of containerized workloads and related machine learning assets. Open Horizon is building an integration project that will demonstrate delivery and management of EdgeX Foundry as a containerized solution in stages, beginning with a single deployable unit and then progressing to a more modular set of services and alternate delivery targets.

Support from Contributing Members and Users of EdgeX Foundry:

 “To further enhance use in production environments, EdgeX Foundry’s Geneva release brings simplified deployments and improved security,” said Tony Espy, Technical Architect at Canonical. “With EdgeX available as a snap, this aligns to the fundamentals of snaps’ core principles which allow developers to benefit from confinement and transactional updates to ensure deployments are secure and with minimal need for manual intervention. As the EdgeX ecosystem continues to see strong traction, we look forward to continuing our contribution to building an open, interoperable framework for edge computing.”

“EdgeX Foundry’s middleware solution is an important component of an open, vendor-neutral pipeline connecting IoT devices and their data to analytics and data management at the on-premise edge,” said Joe Pearson, Engineering Strategy & Innovation Leader, Edge Computing, IBM. “This latest release underscores the importance of working within LF Edge to encourage interoperability as we build a comprehensive open edge computing framework, beginning with Open Horizon.”

“With the evolution of IoT and edge computing, there is a growing realization to deploy and run compute engines near the data source in a truly globally distributed manner. This architecture requires running intelligent AI-based functionality at the edge while processing a significant amount of data at high-throughput and low latency on small form-factor devices,” said Yiftach Shoolman, CTO and co-founder at Redis Labs. “EdgeX Foundry with Redis as the primary data store provides an open-source data platform to meet these expectations by combining in-memory data processing with modern data-models, and can be extended with a serverless engine and AI-serving platform.”

Additional resources:

For more information about LF Edge and its projects, visit https://www.lfedge.org/

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

###

EdgeX Foundry’s Geneva Release and Plans for Hanoi

By Blog, EdgeX Foundry

Written by Jim White, Co-Chair of the EdgeX Foundry Technical Steering Committee and CTO of IOTech

Every six months, the EdgeX Foundry technical community gets together to review its recent release (collecting lessons learned, assembling release notes, etc.) and to plan out its next release.  For the last three years, these meetings have been face-to-face events held in venues across the globe.  It has become an event which many in the community have come to enjoy as it allows us to celebrate our success, plan out the next release, and at the same time reconnect with people that have become close professional friends.

Alas, the global pandemic claimed another causality – albeit a far less important one in relation to world events – when we had to cancel our face-to-face meeting this spring.  We held a virtual event instead and, though different, it was still fun and successful – thanks to the incredible efforts of the development community that has been the life blood of the project since the project’s inception.  We had more than 35 members attending the online sessions each day and managed to get everything accomplished that we planned and even had time for a mini-educational conference (called the “Unconference”) that allowed community members to highlight new EdgeX-based solutions and new project ideas.

The Geneva Release

Our planning meeting is always at the tail end of our current release efforts.  We have an EdgeX development “freeze” period, which means no more feature coding can be done as we clean up bugs and tackle documentation.

Codenamed “Geneva” – this is is EdgeX Foundry’s sixth release but the first for 2020. The highlights of the Geneva release include:

  • Dynamic or automatic device on-boarding – for protocols where it makes sense, this allows EdgeX to automatically provision new sensors and have the sensor data start to flow through EdgeX
  • Alternate messaging support – where applicable, allows adopters to use any messaging implementation under the covers of EdgeX to include MQTT, 0MQ, or Redis Streams.
  • Better type information is associated to sensor data – allowing analytics packages and other users of EdgeX sensor data to more easily digest the data and aid in transformations on the data
  • REST device service
  • Batch and send export – allowing sensor data to be sent to cloud, on-prem or enterprise systems at designated times
  • Support for MQTTS and HTTPS export
  • Redis as the default DB – deprecating MongoDB for license, footprint/performance, and ARM support reasons
  • Adding the Kuiper rules engine – a new rules engine that is smaller and faster and written in Go which replaces EdgeX’s last Java micro service.
  • Improved Security
  • Interoperability testing
  • Improved DevOps CI/CD – now using Jenkins Pipelines to produce EdgeX Foundry project artifacts

The Hanoi Release

As for our semi-annual planning meeting, we set up the scope of our next release which is codenamed “Hanoi.”

There are some significant notable features in this upcoming release which is scheduled to arrive in the October/November 2020 timeframe.

  • Device service to application service message bus – allowing data to “stream” more directly (faster) through EdgeX without persistence.
  • Improve support for running device services on different hosts
  • Secure service to service communications – enabling EdgeX services to live on different hosts and communicate securely
  • Data filters in the device service – allowing repetitive or meaningless sensor data to be discarded sooner in the collection process
  • Performance guidance – giving adopters better understanding of hardware requirements and data flows which can help them architect edge solutions for their use case
  • Improved interoperability testing
  • Hardware Root of Trust abstraction – allowing EdgeX’s to get its secret store master key from hardware secure storage

EdgeX APIs and the EdgeX 2.0 Future

More importantly, this release will include work on a new API set for our microservices.  We call this the V2 API set.  As the name implies, it will be the EdgeX APIs that will be featured in version 2 of EdgeX in the near future (perhaps as soon as 2021).  A portion of the V2 APIs will be available for exploration with the Hanoi release – allowing developers to experiment and test the new APIs.

During the Hanoi release, as we work on V2 API, we are making the APIs easier to use, decoupling data elements used in the message communication from the operations, and generally allowing for better security, better testing, use of different transport infrastructure, and easier extension of the APIs going forward.  So, while Hanoi is expected to be a minor version, it provides the footing for a new major release (EdgeX 2.0) next year.

We invite you to have a look at the new EdgeX release – Geneva.  Learn more here: https://www.edgexfoundry.org/release-1-2-geneva/. Here is hoping that the next six months bring health and safety back to all of our lives and that we’ll be able to reconvene the community of EdgeX Foundry experts soon.

 

EdgeX Foundry IoT Innovation Challenge – Phase 1 Complete

By Blog, EdgeX Foundry

Written by Clinton Bonner, VP of Marketing for Topcoder

We recently told you about an awesome challenge series on Topcoder—focused on using on-demand talent for EdgeX Foundry IOT innovation. Often a new tech philosophy needs an enabling catalyst for it to gain traction. For the Industrial IoT, EdgeX Foundry from the Linux Foundation is that catalyst. EdgeX Foundry is a vendor-neutral open source project hosted by LF Edge building a common open framework for IoT edge computing.

In Phase 1 of this series, EdgeX Foundry tapped the Topcoder community to conceptualize new and unique industry use cases that leveraged the EdgeX Platform. The concepts were procured through this work.

Well, the winners are in! LF Edge, EdgeX Foundry and the teams from Dell Technologies, Intel, HP, IOTech, and Wipro were impressed with the wide variety of innovative use case ideas and technical explanations as to how the EdgeX stack would be leveraged.

Here are the top 5 winning submissions:

1. cunhavictor (Brazil) – Fuel Inventory Control for Oil & Gas Downstream Industry

Synopsis: Product losses during fuel tank truck’s loading and offloading operations, as well as thefts, are common problems that translate to costs estimated around $133 Billion for players in the oil & gas downstream industry. The winning idea is a system for inventory control and loss/theft assessment that joins data from different sensors in a distributed processing architecture. Data integration is usually not handled properly by fuel distribution companies and the system would solve that.  This integration not only has potential to reduce losses but help the fuel distribution company, gas station owners (retail outlets), the end user, and even refineries, to understand how inventory losses occur and to protect their assets.

“Excellent articulation of the business problem, instrumentation options, and how the data will be integrated. You have great domain expertise & clarity of thought.” – Challenge judge

2. wiebket (Netherlands)  – Clinic Occupancy Monitoring System

Synopsis: Traveling to a clinic for a checkup is expensive and time consuming for many people in South Africa. Clinic managers have little oversight into patient flow through the clinic. The clinic occupancy monitoring system uses video cameras and door sensors connected to the EdgeX platform to accurately monitor unique patient visits and real time clinic occupancy without sending patient image data to the cloud. The beneficiaries of such a system are patients, clinic managers and the National Department of Health.

3. vivkv (India) – Machinery and Power Consumption Management

Synopsis: Gather sensor data through EdgeX device services and create an application/algorithm for machinery and power consumption management through the use of advanced analytics and machine learning solutions. This would be done in an integrated manner to maximize ROI on the assets and remain closely bound to the overall business budget.

4. Gungz (Indonesia) – Factory Smart Bin

Synopsis: Create an intelligent smart bin that can send the information about its fill level (volume) and weight to EdgeX platform and then, based on the fill level (volume) of the bin, EdgeX platform can send commands to AGV (Assisted Guided Vehicle) to automatically come and empty the trash bin. Using this approach, a factory can automate its waste tracking and waste disposal without human intervention.

5. kavukcutolga (Turkey) – EdgeX Parking Management

Synopsis: This proposal aims to decrease the time, money, and pollution caused by drivers spending time trying to find a parking spot by using IoT Devices such as Object and Distance sensors.

Congratulations to the top five winners. This concludes Phase 1 of this challenge series and now we’re moving on to Phase 2. The second phase will be a challenge where members pick three of the top ideas and build a Technical Design Document detailing the Technical gameplan of how an idea would be brought to life.

We’d like to thank LF Edge, EdgeX Foundry, Dell Technologies, Intel, HP, IOTech and Wipro for pushing innovation and collaboration that accelerates the deployment of IoT solutions. If you’d like to use on-demand talent in a similar manner to accelerate your technology goals, contact Topcoder here.

For additional information about LF Edge or EdgeX Foundry: