Category

EdgeX Foundry

EdgeX Foundry Challenge Shanghai 2020 was a success!

By Blog, EdgeX Foundry, Event

Written by  co-chairs of the EdgeX Foundry China Project Melvin Sun, Senior Marketing Manager for the IoT Group at Intel, and Gavin Lu, R&D Director OCTO at VMware

On Thursday, September 24, after more than 2 months of fierce competition, the EdgeX Foundry Challenge Shanghai 2020 culminated in the final roadshow. Companies, colleges, hacker teams and enthusiastic audiences from around the world participated in the live video broadcast.

Yingjie Lu, Senior Director of IOT Group in Intel Corporation and Jim White, CTO of IOTech Systems and Chairman of EdgeX Foundry Technical Steering Committee, delivered opening and closing speeches for the final roadshow respectively. Mr. Peng Jianzhen, Secretary General of CCFA (China Chain-store & Franchise Association), and Mr. Shu Bin, experts from China State Grid, made summarizing remarks on all the teams of commerce and industrial tracks respectively.

The EdgeX Challenge Shanghai 2020 is an international hackathon event based on EdgeX, Foundry. It was successfully kicked off as a joint effort among EdgeX community members Canonical, Dell Technologies, HP, Intel, IOTech, Tencent, Thundersoft, VMware and Shanghai startup incubator Innospace.

In the age of the Internet of Things, collaboration is the foundation of all technological and business innovation. And such a spirit can be spread and practiced through the EdgeX community. Today, the EdgeX community members have collaborated extensively across the globe to drive technological development and business prosperity in the global IoT industry.

40 teams submitted their proposals covering both commerce and industrial tracks, including retail, assets tracking, manufacturing, environmental protection and energy conservation, utilities and building automation. The cutting-edge technologies adopted in the works, such as edge computing, artificial intelligence, 5G, sensors, blockchain, satellite communications, Internet of Things and big data, fully demonstrate the strength of innovation and foreshadowing the development and transformation of future life.

After careful selection by the judges, a total of 15 teams were selected as finalists on July 24. Based on the Devkits by Intel and the EdgeX challenge committee, these teams started use cases in various verticals, solving industry pain points, empowering deployable applications, and committing themselves to build a feast of technological innovation and change. The expert judges focused on the development process of the teams and worked with them with daily Q&As, weekly discussions and mid-term check-point meetings.

This Hackathon event has been running smoothly in a tense and methodical atmosphere with strong strength and support. As of mid-September, 15 teams had submitted their final projects, culminating in the finals. Click here to watch snapshot video of the EdgeX Challenge finalists preparing for the competition.

List of teams for roadshow:

Commerce Track

Sequence Code of team Name of team Use Cases Time
1 c18 HYD Miracle Innovation Apparel store edge computing 9:12
2 c27 DreamTech Mortgage assets monitoring based on blockchain +edge computing 9:24
3 c16 USST,YES! Retail store edge 9:36
4 c19 Breakthrough Studio Scenic Intelligent Navigation 9:48
5 c26 i-Design Edge-cloud based far ocean intelligent logistics/monitor 10:00
6 c07 Starlink team from JD.com Retail store heatmap & Surveillance 10:12
7 c03 AI Cooling Building automation 10:24
8 c08 Sugarinc Intelligence Smart building & office management 10:36
9 c10 Five Card Stud fighting force Automobile 4S (sales, service, spare part, survey) store 10:48

Industrial Track

Sequence Code of team Name of team Use Cases Time
1 i07 VSE Drivers school surveillance & analytics 11:00
2 i09 Smart eyes recognize energy CV based intelligent system of meters recognition 11:12
3 i01 Baowu Steel Defects detection in steel manufacture 11:24
4 i08 CyberIOT Guardians of electrical and mechanical equipment 11:36
5 i10 Power Blazers Autotuning system for orbital wind power system 11:48
6 i06 Jiangxing Intelligence Intelligent Edge Gateway for Industrial 12:00

 

Note: The sequence of the roadshow above is determined by the drawing of lots by the representatives of each participating teams.

The live roadshow was successfully broadcasted on September 24, where all the final teams presented their proposals and interacted with the judges. To ensure a comprehensive and professional assessment, the organizer invited expert judges with blended strong background, including:

– Business experts: Gao Ge, General Manager of Bailian Group’s Science and Innovation Center; Violet Lu, IT director of Fast Retailing LTD; and Yang Feng, Head of Wireless and Internet of Things of Tencent’s Network Platform Department

– EdgeX & AIOT experts: Henry Lau, Distinguished Technical Expert on Retail Solutions in HP Inc.; Gavin Lu, Director in VMware (China) R&D Center; Jim Wang, senior expert on IoT in Intel Corporation; Chris Wang, director of artificial intelligence in Intel; Jack Xu and Mi Wu, IoT experts in Intel; Xiaojing Xu, Senior Expert, Thundersoft Corporation

– Representatives from the investment community: Riel Capital, Intel Capital, VMware Capital …… In addition, the quality of the team & proposals attracted a large number of investment institutions, including Qiming Venture Capital, Morningside Capital, ZGC Qihang Investment, and other professional investors constitute the Members of the observer group for this live roadshow.

During the live streaming roadshow, all the teams’ works demonstrated the unique advantages of EdgeX in IoT and the edge computing development. The judges provided feedback and suggestions for Creativity, use of Computer Vision, Impact, Viability, Usefulness, simplicity, as well as documentation preparation and performance in the roadshow session. Observers and fans from all over the world also expressed their opinions through messaging and comment sections, which made the competition exciting.

The live roadshow has ended but the organizing committee is still in the process of collecting the judges’ questions and compiling the teams’ answers. Based on the above information, the competition will carefully score the ideations and demos to filter out competitive & deployable solutions to customer’s pain points. Meanwhile, we will hold an award ceremony at the Global Technology Transfer Conference on October 29, where the winners will receive a total of 90,000 RMB in cash prizes and rich rewards for their efforts.

Video playback of the final roadshow will be available on bilibili website, if you are interested in watching it, please follow the channel of EdgeX China Project on Bilibili. For more about the EdgeX Foundry China Project, visit the wiki at https://wiki.edgexfoundry.org/display/FA/China+Project.

On the “Edge” of Something Great

By Akraino, Announcement, Baetyl, Blog, EdgeX Foundry, Fledge, Home Edge, LF Edge, Open Horizon, Project EVE, Secure Device Onboard, State of the Edge

As we kick off Open Networking and Edge Summit today, we are celebrating the edge by sharing the results of our first-ever LF Edge Member Survey and insight into what our focuses are next year.

LF Edge, which will celebrate its 2nd birthday in January 2021, sent the survey to our more than 75 member companies and liaisons. The survey featured about 15 questions that collected details about open source and edge computing, how members of the LF Edge community are using edge computing and what project resources are most valuable. 

Why did you chose to participate in LF Edge?

The Results Are In

The Top 3 reasons to participate in LF Edge are market creation and adoption acceleration, collaboration with peers and industry influence. 

  • More than 71% joined LF Edge for market creation and adoption acceleration
  • More than 57% indicated they joined LF Edge for business development
  • More than 62% have either deployed products or services based on LF Edge Projects or they are planned by for later this year, next year or within the next 3-5 years

Have you deployed products or services based on LF Edge Projects?

This feedback corresponds with what we’re seeing in some of the LF Edge projects. For example, our Stage 3 Projects Akraino and EdgeX Foundry are already being deployed. Earlier this summer, Akraino launched its Release 3 (R3) that delivers a fully functional open source edge stack that enables a diversity of edge platforms across the globe. With R3, Akraino brings deployments and PoCs from a swath of global organizations including Aarna Networks, China Mobile, Equinix, Futurewei, Huawei, Intel, Juniper, Nokia, NVIDIA, Tencent, WeBank, WiPro, and more. 

Additionally, EdgeX Foundry has hit more than 7 million container downloads last month and a global ecosystem of complementary products and services that continues to increase. As a result, EdgeX Foundry is seeing more end-user case studies from big companies like Accenture, ThunderSoft and Jiangxing Intelligence

Have you gained insight into end user requirements through open collaboration?


Collaboration with peers

The edge today is a solution-specific story. Equipment and architectures are purpose-built for specific use cases, such as 5G and network function virtualization, next-generation CDNs and cloud, and streaming games. Which is why collaboration is key and more than 70% of respondents said they joined LF Edge to collaborate with peers. Here are a few activities at ONES that showcase the cross-project and members collaboration. 

Additionally, LF Edge created a LF Edge Vertical Solutions Group that is working to enable easily-customized deployments based on market/vertical requirements. In fact, we are hosting an LF Edge End User Community Event on October 1 that provides a platform for discussing the utilization of LF Edge Projects in real-world applications. The goal of these sessions is to educate the LF Edge community (both new and existing) to make sure we appropriately tailor the output of our project collaborations to meet end user needs. Learn more.

Industry Influence

More than 85% of members indicated they have gained insights into end user requirements through open collaboration. A common definition of the edge is gaining momentum. Community efforts such as LF Edge and State of the Edge’s assets, the Open Glossary of Edge Computing, and the Edge Computing Landscape are providing cohesion and unifying the industry. In fact,  LF Edge members in all nine of the projects collaborated to create an industry roadmap that is being supported by global tech giants and start-ups alike.

 

 

Where do we go from here? 

When asked, LF Edge members didn’t hold back. They want more. They want to see more of everything – cross-project collaboration, end user events and communication, use cases, open source collaboration with other liaisons. As we head into 2021, LF Edge will continue to lay the groundwork for markets like cloud native, 5G, and edge for  more open deployments and collaboration.  

 

LF Edge Member Spotlight: NetFoundry

By Blog, EdgeX Foundry, LF Edge, Member Spotlight

The LF Edge community comprises a diverse set of member companies and people that represent the IoT, Enterprise, Cloud and Telco Edge. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source edge solutions. Today, we sit down with Jim Clardy, Co-Founder and Global Cloud Partners and Alliances at NetFoundry, to discuss the importance of open source, collaborating with industry leaders in edge computing and the impact of being a part of the LF Edge ecosystem.

Please tell us a little about your organization.

NetFoundry provides the leading zero trust networking platform offered as Network-as-a-Service (NaaS) to connect distributed applications, users, devices and locations through an optimized  global fabric. This enables: solutions and applications, ranging from edge to cloud, to easily embed zero trust networking inside the solution. Developers can embed secure, programmable, private, application-specific networking into their apps, using the open source Ziti software (Ziti.dev) which NetFoundry built and is the leading contributor to.

 

Why is your organization adopting an open source approach?

NetFoundry is built on open source Ziti. The next paradigm in networking is “Networking as code” and zero trust. With open source Ziti SDKs, developers can embed private networking into apps with a few lines of code. Ziti enables a new networking paradigm that greatly reduces the costs and simplifies the complexity of networking and implements zero-trust application embedded connectivity. Ziti is the leading open source platform for creating zero trust network connectivity over the Internet.

Why did you join LF Edge and what sort of impact do you think it has on the industry?

We believe open source communities have the power to shape technologies and markets. In addition to LF Edge, we are members of the Linux Foundation, EdgeX Foundry, and CNCF communities.

What do you see as the top benefits of being part of the LF Edge community?

Accelerating the next paradigm in networking where networking as code and zero trust become ubiquitous. We believe networking will be transformed with cloud-orchestrated interoperability fueled by open source communities like LF Edge.

What contributions has your team made (or plans to make) to the community/ecosystem through LF Edge participation?

NetFoundry built and is the leading contributor to open source Ziti software, and we are excited to build the open Ziti community. NetFoundry is contributing code to open Ziti regularly.

What do you think sets LF Edge apart from other industry alliances?

You are able to draw on the Linux Foundation and related ecosystem of communities and contributors – there is a massive and unstoppable network effect created by LF Edge.

How might LF Edge help your business?

Accelerate the development of the Ziti project and community.

 

What advice would you give to someone considering joining the LF Edge community?

Don’t wait – do it today.

Learn more about NetFoundry here.

Learn more about open Ziti here.

Get started with Ziti on GitHub.

To find out more about our members or how to join LF Edge, click here. Additionally, if you have questions or comments, visit the  LF Edge Slack to share your thoughts and engage with community members.

 

 

LF Edge Demos at Open Networking & Edge Summit

By Blog, EdgeX Foundry, Event, Fledge, LF Edge, Open Horizon, Project EVE, Secure Device Onboard

Open Networking & Edge Summit, which takes place virtually on September 28-30, is co-sponsored by LF Edge, the Linux Foundation and LF Networking. With thousands expected to attend, ONES will be the epicenter of edge, networking, cloud and IoT. If you aren’t registered yet – it takes two minutes to register for US$50 – click here.

Several LF Edge members will be at the conference leading discussions about trends, presenting use cases and sharing best practices. For a list of LF Edge focuses sessions, click here and add them to your schedule. LF Edge will also host a pavilion – in partnership with our sister organization LF Networking – that will showcase demos, including the debut of two new ones that feature a collaboration between Project EVE and Fledge and Open Horizon and Secure Device Onboarding. Check out the sneak peek of the demos below:

Managing Industrial IoT Data Using LF Edge (Fledge, EVE)

Presented by Flir, Dianomic, OSIsoft, ZEDEDA and making its debut at ONES, this demo showcases the strength of Project EVE and Fledge. The demo Fledge will show how the two open source projects work together to securely manage, connect, aggregate, process, buffer and forward any sensor, machine or PLC’s data to existing OT systems and any cloud. Specifically, it will show a FLIR IR Camera video and data feeds being managed as described.

 

Real-Time Sensor Fusion for Loss Detection (EdgeX Foundry):

Presented by LF Edge members HP, Intel and IOTech, this demo showcases the strength of the Open Retail Initiative and EdgeX Foundry. Learn how different sensor devices can use LF Edge’s EdgeX Foundry open-middleware framework to optimize retail operations and detect loss at checkout. The sensor fusion is implemented using a modular approach, combining point-of-sale , computer vision, RFID and scale data into a POC for loss prevention.

This demo was featured at the National Retail Federation Show in January. More details about the demo can be found in HP’s blog and  Intel blog.

               

Low-touch automated onboarding and application delivery with Open Horizon and Secure Device Onboard

Presented by IBM and Intel, this demo features two of the newest projects accepted into the LF Edge ecosystem – Secure Device Onboard was announced in July while Open Horizon was announced in April.

An OEM or ODM can generate a voucher with SDO utilities that is tied to a specific device. Upon purchase, they can send the voucher to the purchaser. With LF Edge’s Open Horizon Secure Device Onboard integration, an administrator can load the voucher into Open Horizon and pre-register the device. Once the device is powered on and connected to the network, it will automatically authenticate, download and install the Open Horizon agent, and begin negotiation to receive and run relevant workloads.

For more information about ONES, visit the main website: https://events.linuxfoundation.org/open-networking-edge-summit-north-america/. 

Exploration and Practices of Edge Computing: Cloud Managing Containerized Devices

By Blog, EdgeX Foundry, Industry Article, Trend

Written by Gavin Lu, LF Edge member, EdgeX Foundry China Project Lead and R&D Director in the VMware Office of the CTO

As an industry leader with vast experience and knowledge, Gavin has been writing a series of articles focused on edge computing. These articles are posted on his personal blog and are posted here with his permission. To read more content from Gavin, visit his website.

Introduction

The previous article introduced the cloud management virtualization device solution. This article will describe the Nebula project, a unified management of containerized devices and edge applications and data analysis cloud services.

Nebula Architecture

Project Nebula is designed based on the following key ideas:

  • Agnostic to device CPU architecture, supporting both x86 and ARM;
  • Agnostic to edge application frameworks, supporting EdgeX Foundry and other frameworks that can be packaged and run;
  • Agnostic to data analytics services, supporting on-premise and cloud deployment;
  • Support small to large scale deployment;
  • Support end-to-end multi-tenant operation model from device to cloud.
EdgeX Foundry Architecture

Nebula supports EdgeX Foundry framework, and we already published a live test bed at https://18.189.42.126/. Those who are interested in Nebula could contact yixingj@vmware.com to register for a trial, installation and user guides with detailed information.

Nebula Demo

Installation

Nebula is designed in containerized micro-service architecture, and is installed by default in OVA format. Similar to Pallas architecture introduced in the previous article, although Nebula package is encapsulated in OVA, it does not depend on any specific virtualization infrastructure or cloud platform to be installed. Technically, it could completely be converted to other formats, or install on any cloud platform that supports OVA format.

The basic resource requirement of Nebula is:

  • CPU: 2 virtual CPU cores
  • Memory: 8GB
  • Storage: 150GB

Its installation process is similar to other normal OVA, and users can log in as the administrator after completion.

Nebula Service Console

Vendor Portal

After the installation is complete, users can log in to the vendor portal as an administrator according to the prompt address in VM console as above and perform user management.

Nebula Management Portal

In Nebula, edge application services are defined as following: A Service can contain multiple Versions, and a Version contains multiple Service Components.

Edge Service Hierarchy

For each service created, it is necessary to determine parameters and resource requirement such as version, CPU platform, memory, storage, network, etc., to facilitate verification in full life cycle management.

Vendors can upload a set of EdgeX Foundry applications packaged in container images, and define categories, dependencies between containers, resource parameters, startup order, and parameters of connected data analysis cloud services.

After the release, users can see and deploy these edge services.

Device Registration

Before users actually deploy EdgeX Foundry applications, they must first register the device they would use into their Nebula accounts.

Users need to download Nebula agent program nebulacli.tar by themselves and run it on the device to complete the registration. This registration step could be manual, or it can be automated in batch operations for OEM.

./install.sh init -u user-acccount -p user-account-password -n user-device-name

User Portal

After completing the device registration, users can install and manage EdgeX Foundry or other edge applications released in advance on Nebula service by vendors. Users can find proper applications in the catalog.

After selection, users can further specify parameter settings of the deployment in the drag-and-drop wizard, which maps to parameter values defined by the vendor before.

After all parameters are set, the actual deployment can be carried out, either in batch or multiple times to multiple devices. After deploying EdgeX Foundry applications, users can monitor device resources and application run time status in real time.

Nebula provides complete Restful API documentation, with which users can automate operations to deploy EdgeX Foundry applications in a large scale.

Next

From the second article to this article, I introduced the basic method of building and managing virtualized devices and containerized devices from the cloud. But I did not answer the question of how to deal with single-point device failure. Compared with the traditionally inflexible and inefficient full redundancy or external NAS solution, the next article will introduce device clusters on hyper-convergence architecture.

EdgeX Foundry Welcomes New Contributors for Q2

By Blog, EdgeX Foundry

Written by Aaron Williams, LF Edge Developer Advocate

The second quarter has been really busy for the EdgeX community.  We released Geneva and are working hard on Hanoi, our fall release.  This release was made possible through the hard work of 52 community members contributing code in GitHub over the past three months.  Over the past three years, EdgeX has enjoyed 117 unique contributors and the community is continuously growing. We want to welcome and recognize our four first time contributors from Q2.

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.

Q2 New Contributors’ Usernames:

nbfhscl

bill-mahoney

charles-knox-intel

wogsland

You can find these contributors on github and see what other projects they are working on.

We would be remiss if we didn’t thank our other contributors who posted code, help with documentation, or answered questions on our slack workspace in Q2.   We had over 80k lines of code committed from 50 unique (66 YTD) developers making 665 commits (1.3k YTD).  And here are our top ten committers for the second quarter:

lenny-intel tonyespy
ernestojeda rsdmike
cherrycl difince
lranjbar iain-anderson
hahattan jamesrgregg

You can find most of them on our slack workspace (edgexfoundry.slack.com) where we have had over 2000 messages from 101 members!  On our slack channels, you can ask questions and get help, or you can follow our working groups’ channels.

Do you want to get involved with EdgeX Foundry-The World’s First Plug and Play Ecosystem-Enabled Open Platform for the IoT Edge or just learn more about the project and how to get started?  Either way, visit our Getting Started page and you will find everything that you need to get going.  We don’t just need developers, we could use tech writers, translators, and many other disciplines.

EdgeX Foundry is an open source project hosted by LF Edge that is building a common open platform for IoT Edge computing. The interoperable platform enables an ecosystem of plug-and-play components that unifies the marketplace and accelerates the deployment of IoT solutions across a wide variety of industrial and enterprise use cases.

EdgeX is unique in its scope, broad industry support, credibility, investment, vendor-neutrality, and Apache 2.0 open source licensing model. As such, EdgeX is a key enabler of digital transformation for IoT Use Cases and businesses across many different vertical markets.

EdgeX offers all interested developers or companies the opportunity to collaborate on IoT solutions built using existing connectivity standards combined with their own proprietary innovations.

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!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LF Edge Member Spotlight: Mocana

By Blog, EdgeX Foundry, LF Edge, Member Spotlight

The LF Edge community comprises a diverse set of member companies and people that represent the IoT, Enterprise, Cloud and Telco Edge. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source edge solutions. Today, we sat down with Dave Smith, President of Mocanato discuss the importance of open source, collaborating with industry leaders in edge computing, security, how they leverage the EdgeX Foundry framework and the impact of being a part of the LF Edge ecosystem.

Can you tell us a little about your organization?

Mocana revolutionizes OT and IoT with cyber protection as a service for trustworthy systems. The company helps device operators bridge the adoption challenge between vendors and service providers, and delivers key cybersecurity benefits to the emerging 5G network, edge computing applications, and SD-WAN enterprise networks. Mocana protects the content delivery supply chain and device lifecycle for tamper-resistance from manufacture to end of life, with root-of-trust and chain-of-trust anchors. Mocana measures devices for sustained integrity and the trustworthiness of operations and data to power artificial intelligence/machine learning analytics. The Mocana team of security professionals works with semiconductor vendors and certificate authorities to integrate with emerging technologies to comply with data privacy and protection standards. The goal of cyber protection as a service is to eliminate the initial cost of modernization for device vendors and empower service providers to offer subscription-based services for the effective and efficient expansion of corporate and industrial digital transformation strategies.

Mocana’s core technology protects more than 100 million devices today, and is trusted by more than 200 of the largest energy, government, healthcare, manufacturing, IoT, telecommunications & networking, and transportation companies globally.

Why is your organization adopting an open-source approach?

Mocana is eager to support the global body of customers adopting the EdgeX Foundry open source solution. OpenSSL is by far the most broadly integrated and implemented open source security stack. It comes freely available and is distributed as part of the LF Edge distributions. However, in recent years OpenSSL has come under scrutiny because of critical security vulnerabilities and the resulting issuance of CVEs. The Heartbleed vulnerability from 2014 was a notable exploit, and there are several other recent CVEs that have generated concern in the information security community. The strategy of taking a defensive position through ongoing patching of vulnerabilities continues to challenge efforts to protect mission-critical OT environments.

Since the founding of the LF Edge projects, the goal has been to pull together a body of code to standardize the microservices delivery and orchestration for edge computing systems and devices. The projects continues to advance commercial third-party solutions to address key functional areas, especially for mission-critical and vertical industry applications. Mocana’s solution is based upon a commercially supported, NIST FIPS 140-2 certified, cryptographic module. Many of the company’s Fortune 500 customers have realized significant benefits from the ability to quickly migrate from default products integrated with OpenSSL to Mocana’s offering, leveraging its OpenSSL connector.

Why did you join LF Edge, and what sort of impact do you think LF Edge has on edge computing, networking, and IoT industries?

Developing, deploying, operating, and managing IoT and edge computing requires a community of key, forward-looking technology innovators. The IoT-edge ecosystem spans a wide supply chain from first silicon to the cloud, and includes system integrators, end-user operators and asset owners. Mocana was one of the first 50 founding members of EdgeX Foundry in 2017. Early on, the company took an industry leadership position by driving industry adoption through off-the-shelf solutions developed through stakeholder collaboration. This approach addressed a variety of common use cases delivered by new edge computing technologies and applications, and required much more than a reference architecture. Mocana recognized the need for the user community and developing ecosystem to leverage community-developed code (e.g. Github) to reduce feature and software code duplication and enable the broadest possible market adoption. The customer benefit reduces the implementation risk for such new technologies and accelerates community stakeholder time to market.

What do you see as the top benefits of being part of the LF Edge community?

Mocana values LF Edge’s ecosystem breadth and depth of community members and stakeholders, which includes chip companies, device ODMs, OEMs, carrier service providers, and asset owner/operators. Each contributes key use case challenges that have been invaluable for ensuring that LF Edge can support key technology developments and marketplace challenges.

What sort of contributions has your team made to the community, ecosystem through LF Edge participation?

As key contributor to the community, Mocana worked with the EdgeX Foundry Security Working Group and offered insights and guidance on vital security use cases. The company ensured there was always a path to address developing cybersecurity mandates and best practices from NIST Cybersecurity Framework and ISA/IEC 62443. As a result, the community has delivered a number of key security functions. They added a reverse proxy, provided a method to secure the key store with the ability to manage it, and has integrated access to session-based security to the microservices.

Perhaps most important, Mocana has enabled the community to incorporate a scalable, robust, and commercially supported cybersecurity offering for EdgeX Foundry production development and deployments.

Mocana developed its OpenSSL connector to ease migration from default project configurations with OpenSSL to Mocana’s TrustCenter and TrustPoint offerings. This solution aligns well with the project’s objectives to accelerate adoption and deployments of standardized implementations addressing key edge computing use cases with microservices.

What do you think sets LF Edge apart from other industry alliances?

Delivering actual code that organizations can download, compile, run, and then operate is a tremendous benefit compared to most other industry alliances. It is a major differential in comparison to groups that only suggest frameworks and prescriptions of possible features, implementations, and suggested “best practices.”

How will LF Edge help your business?

Demand is growing for edge computing solutions. Hitting 5 million downloads of the EdgeX Foundry SDK in May are proof of that. Mocana also is beginning to see initial commercial success and adoption in the innovation and R&D centers by key community members. The company’s ability to enable its fully integrated TrustCenter and TrustPoint solutions leveraging an OpenSSL connector provides a clear and rapid path to EdgeX device security lifecycle management and supply chain provenance. Plus, it will increase adoption of Mocana’s latest edge device offerings from the community.

What advice would you give to someone considering joining LF Edge?

Find your niche in one of LF Edge’s nine collaborative projects where your offering can deliver the most value and contribute. There has never been a better time to participate in this open source community, which is looking for complementary solutions and ways to deepen the ecosystem.

To learn more about EdgeX Foundry, click here. To find out more about our members or how to join LF Edge, click here.

Additionally, if you have questions or comments, visit the  LF Edge Slack or the EdgeX Foundry Slack to share your thoughts and engage with community members.

Exploration and Practices of Edge Computing: Cloud Managing Virtualized Devices

By Blog, EdgeX Foundry

Written by Gavin Lu, LF Edge member, EdgeX Foundry China Project Lead and R&D Director in the VMware Office of the CTO

As an industry leader with vast experience and knowledge, Gavin has been writing a series of articles focused on edge computing. These articles are posted on his personal blog and are posted here with his permission. To read more content from Gavin, visit his website

Introduction to the Architecture of Pallas

The previous article introduced how to build and install virtualized devices, but did not touch how to manage large-scale virtualized devices from the cloud. This article introduces the architecture of Pallas to achieve the above goal.

Pallas is the second milestone of the project Asteroid after Ceres. In this release, the basic problems of cloud managing virtualized devices are solved:

  • The device-cloud connection is narrow and unstable
  • Large scale of devices
  • Serious security concerns, often forbidding any open ports

The main functions of the Pallas architecture are implemented by the device manager and the agent virtual machine. Its design key points are:

  • Adopt MQTT protocol suitable for narrow-band, unstable network connections
  • The device manager in the cloud adopts the design concept of typical Internet architecture, with multiple layers, micro-services, multiple buffers, and read-write separation
  • The device is automatically registered to the device manager, and the device initiates all connections and response happens in the cloud
  • Close all ports on the device, run without VPN / SD-WAN, cross public networks
  • Each device has a randomly created, globally unique and permanent ID

Installation requirements

  • vSphere Hypervisor is installed on the device.
    • Device agent
      • CPU: 1 x86-64 vCore
      • Memory: 512MB
      • Storage: 5GB
  • Device manager
    • CPU: 2 vCores
    • Memory: 8GB
    • Storage: 100GB
    • Network: Open ports 443 and 1883, the device is visible

Note: In order for the agent to work properly, the device requires at least vSphere Essentials Kit license, or apply for the Enterprise Edition 60-day trial using the method described in the previous article. 

Download and Installation

Download Pallas

The Pallas installation package can be downloaded from the Flings website of the VMware CTO office. You need to register a VMware community account in advance. The download package contains the device manager OVA, agent VM OVA and user guide.

Note: The download package provided on the Flings website is a technical preview, which does not include commercial support. It is recommended that you carefully read its installation and user guide before initialize the installation.

Install device manager

The way to install device manager is the same as the typical way to install an OVA of virtual machines, which can be completed in sequence by referring to the steps in the Pallas installation guide.

Note: Although device manager is packaged in OVA mode, it does not depend on any specific virtualization infrastructure or cloud platform. In an alternative, it can be converted from OVA to other formats, or install on any cloud platform that supports OVA format.

Install device agent

In order to simplify the process of installing device agent, it is recommended to use the virtual machine OVA instead of the binary package.

 
You can use OVF Tools to install OVA remotely, or leverage ESXi UI to install directly as below.

ovftool –acceptAllEulas –name=pallas_agent –datastore=DATASTORENAME -dm=thin –X:injectOvfEnv –powerOn pallas_agent_ubuntu.ova ‘vi://USERNAME:PASSWORD@ESXIHOST’

Configuration and Use

Configuration

Before you start using it, it is critical to configure the device agent. In order to ensure communication security, remember to modify /etc/vmware/pallas_agent/pallas_agent.conf file before encrypt the file in the following manner.
python3 /root/agent/install/encrypte_password.py YOUR-PASSWORD

If the device is connected to the cloud via WiFi or a telco carreir mobile network, the corresponding PCIe or USB NIC needs to be passed through to the device agent virtual machine. In this way, the device agent virtual machine can be registered to the device manager.

Use

After the device is registered to the device manager, you can perform CRUD-like operations on users, devices, and virtual machines like other ordinary management tools.

 
 
 
It should be noted that because the communication protocol of metadata between the device manager and the device is based on MQTT, the status updates of the device and the virtual machine on top of it are completed asynchronously. If you don’t find a task completed in “real time”, you may need to wait for a while or refresh the status.
 
For tasks such as deploying a virtual machine or patching a device, large files are downloaded via HTTPS and auto resuming.
 
To complete all functions
 above, there is no need for mutual IP visibility between the manager and the device, nor the installation of any VPN or SD-WAN. The device can also be safely behind a firewall, NAT, or gateway.
 
 
With the support of these basic functions, it is easy to expand, manage large-scale virtualized devices from the cloud, and deploy edge applications like EdgeX Foundry framework on them. In the workshop on EdgeX Foundry China Day in December 2019, we have demonstrated the deployment of edge applications based on EdgeX Foundry framework with cloud management of virtualized devices.
 
 

Next

The previous two articles described how to build and install virtualized devices, and how to manage virtualized devices from the cloud. 

In the preface, in addition to virtualization devices, another solution is containerized devices.

In fact, the use of containerized equipment is very common, and it often implies local orchestration, cloud operation and maintenance.

  • Local orchestration means that single-point failures of devices cannot be handled well. Even the most common deployment approach of EdgeX Foundry is to deploy core container instances of microservices on one single device.
  • Cloud operation and maintenance means managing containerized devices from the cloud. Most manufacturers have their own specialized solutions, which brings another problem of technology fragmentation.

The solutions to these two problems will be discussed in subsequent chapters. The next article will introduce a cloud managing containerized device solution to solve the problem of fragmentation.

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