Blog

Your Path to Edge Computing: Akraino Edge Stack’s Release 1

By Kandan Kathirvel, Akraino Edge Stack TSC-Chair and Tina Tsou, Akraino Edge Stack TSC Co-Chair

The Akraino community was proud to announce the availability of its release 1 on June 6th. The community has experienced extremely rapid growth over the past year, in terms of both membership and community activity: Akraino includes broad contributions from across LF Edge, with 60% of LF Edge’s 60+ members contributing to project, as well as several other developers across the globe.

Before Akraino, developers had to download multiple open source software packages and integrate/test on deployable hardware, which prolonged innovation and increased cost. The Akraino community came up with a brilliant way to solve this integration challenge with the Blueprint model.

An Akraino Blueprint is not just a diagram; it’s real code that brings everything together so users can download and deploy the edge stack in their own environment to address a specific edge use case. Example use cases include IoT gateway, MEC for connected car, and a RAN intelligent controller that enables 5G infrastructure.

The Blueprints address interoperability, packaging, and testing under open standards, which reduces both overall deployment costs and integration time by users. The Akraino community will supply Blueprints across the LF Edge portfolio of projects, with plans to address 5G, IoT and a range of other edge use cases.

The key strength of the Akraino community is the well-defined process to welcome new Blueprints, new members, users and developers. The technical community is comprised of a Technical Steering committee (TSC), which consists of representatives from across member companies. The TSC acts as a “watchdog” to set process, monitor the community, and ensure open collaboration. In addition to the TSC, the Akraino community has seven sub-committees focused on much-needed areas such as security, edge APIs, CI and validation labs, upstream collaborations, documentation, process and community. Regular meetings are scheduled to ensure broader collaboration and accelerate progress on the various projects. The community calendar can be found here. It is not necessary to be a member to join the community calls, we invite anyone interested in learning more to join!

The above picture illustrates the primary use of Akraino R1 Blueprints and its targeted deployment areas. The release 1 Blueprints cover everything from a larger deployment in a telco-based edge cloud to a smaller deployment, such as in a public building like a stadium. Each Blueprint is validated via community standards on real physical lab hardware, hosted by either the community or the users.

Akraino Edge Stack prides itself on continuous refinement and development to ensure the success of Blueprints and projects. The community is already planning R2, which will include both new Blueprints and enhancements to existing Blueprints, tools for automated Blueprint validations, defined edge API’s, new community lab hardware, and much more. For future events and meetings please visit: https://wiki.akraino.org/display/AK/Akraino+TSC+Group+Calendar.

 

Hello System Management!

Written by Akram Ahmad, EdgeX Foundry contributor and Principal Software Engineer at Dell Technologies

For those of you not yet familiar with the canonical way of introducing new technology-centric stuff, at least the way we do it in the world of computer programming–and thinking here specifically to the “Hello World!” first-ever program introduced to the world by programming legends Kernighan and Ritchie with their C programming language–please allow me to clarify what may be an admittedly enigmatic title we’ve got for this blog post. Essentially, it was with the EdgeX Foundry Delhi Release that the team had the pleasure of introducing EdgeX System Management capability to the world! Hence, “Hello System Management!” (More on the Edinburgh Release in just a bit.)

It’s my ongoing privilege to be a part of helping design, implement, and shepherd System Management (or “SM” for short) to date, and going forward. With that in mind, I would like to give you a flavor of the capabilities that SM brings to the table.

You can think of the System Management Agent (SMA), in particular, as a brand-new service which serves as the coordinator for control plane information (i.e. status, configuration, and metrics for EdgeX services). The SMA also control actions on EdgeX services (i.e. starting, stopping, and restarting services). Cloud or third-party systems can, in turn, call on the API provided by the SMA to trigger the actions or to get the control plane data they need. In a nutshell, the SMA can serve as a one-stop shop for managing a deployed instance of EdgeX.

Each EdgeX micro service has a corresponding management API that the SMA calls on to help control that service (e.g. to stop the service) or fetch its latest configuration or metrics. The SMA, along with the management API provided by each service, will be expanded in future releases of EdgeX and will one day offer control plane data and actions via alternate protocols (for example via the well-known protocol SNMP that is part of the TCP/IP suite that powers the Internet as we know it today).

I invite you to hold on to the thought that, for the constellation of services that will be offered via EdgeX, there needs to be “controller” of sorts…

Now, let’s turn to the truism that an IoT platform like EdgeX is used to collect the data from “Things.” Put another way, the platform ingests data that is physically sensed from IoT sensors and devices. Work associated with collecting, managing, and disbursing sensed data is exactly the kind of work associated with a “data plane.” On the other hand, the kind of work associated with operating and managing the IoT platform software and infrastructure is best described as “control plane” operations.

This includes getting the IoT platform and infrastructure running (or shutdown), configuring the platform software for the particular use case, and understanding the health and status of the software platform (is it running and what type of resources is the IoT software platform using?). Analysis of any control plane data may be used to take action as well, but action revolves around the IoT platform itself–not the sensed or controlled world. For example, in the control plane, it may be determined that a service needs to be restarted because it is consuming too much memory.

This is where the SMA comes in!

The System Management (SM) service will assist in protecting EdgeX and reducing the surface area of an API attack. Rather than opening up access to all services to the central management system, the SM service serves as a single point proxy to the control plane for all of EdgeX services for the central management system. The SMA, therefore, reduces the number of access points to EdgeX and reduces potential security vulnerabilities. It also allows the central management system to be loosely coupled to all of EdgeX—requiring the central management system to again have just one access address (the address of the SM service) that it needs to know about for any EdgeX deployment.

Before digging deeper, let’s recap what we’ve learned so far: System Management (SM) functionality, as determined by the EdgeX community, is generally associated with control plane data and operations.  The control plane (and System Management) is about managing the IoT platform and infrastructure. The data plane is all about managing and understanding the physical world that the IoT platform is there to observe and control. Think about it: Whether one is talking about towering skyscrapers or flimsy tents rigged on the grounds of a park, there remains, as ever, the crucial need for control. Without coordination, things can get chaotic in a heartbeat.

Also, and crucially, SM is also about providing information—having retrieved that information in the first place—about the status of the services it manages. Eventually, building on this capability, SM will provide the means to reconfigure the services themselves. At this time, with the Edinburgh Release, SM can provide performance and memory metrics for requested services. Likewise, SM can provide detailed configuration information for the services requested by users of SM, as well as the health status of those services (whether given services are up or down.)

In other words, while control is a critical capability, SM is about more than just control. By the same token, we want to make it abundantly clear that we are building System Management (SM) capability to facilitate other central systems, and not be those central systems. In a nutshell, EdgeX SM is about helping promote interoperability—in this case, allowing you to manage EdgeX with your choice in central management system.

Let’s shift gears a bit now: When you look at a typical fog deployment, a larger management system will want to manage the control plane of the edge systems as well as all the intermediate and upper level nodes and resources of the overall deployment. Just as there is a management system to control all the nodes and infrastructure within a cloud data center, and across cloud data centers, so too there will likely be management systems that will manage and control all the nodes (from edge to cloud) and infrastructure of a complete fog or IoT deployment.

If you will be so kind as to allow me the use of just one more metaphor, it will be this one: Think to a team of workhorses ploughing the land (EdgeX services). Then think to the driver (System Management). Finally, and without going too crazy about the farming metaphor—all metaphors, including this one, can carry only so much water—I invite you to imagine two scenarios (1) First, the one without the other, and (2) Second, the two (i.e. the team of workhorses and the driver) working in unison. If you associated chaos with the first scenario, and clockwork unison with the second, you are in good company.

So with the Edinburgh Release, we will continue building SM capability to facilitate other central systems. Again, the goal is not to be those central systems, but rather to facilitate those systems. May your System Management (SM) learnings continue, and may the community be the better for it!

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel. Or, join the LF Edge Slack Channel and share your thoughts in the #EdgeX channel.

Project EVE Code Now Available

Project EVE (Edge Virtualization Engine), part of LF Edge since the organization’s inception, earlier this week marked an important milestone: the official handover of code from ZEDEDA. EVE provides an open standard for edge virtualization, helping make it as easy and secure to manage applications on edge devices as it is in the cloud. With EVE, enterprises can run a wide variety of applications on any edge-class gateway while enjoying the benefits of data center virtualization, like zero-touch provisioning and secure, one-click software update rollouts at IoT scale.

“Project EVE’s release under LF Edge is an important milestone for the edge computing industry,” said Melissa Evers-Hood, senior director of Google Operating Systems for Intel System Software Products, and chair of the LF Edge Governing Board. “An open approach to virtualization can help companies address the growth in diverse services and hardware configurations being deployed at the edge. Using virtualization to consolidate workloads provides companies with a more flexible and elastic infrastructure, allowing them to secure and manage these services while containing costs.”

Project EVE  allows applications ranging from legacy software programs running in virtual machines (VMs) to the latest microservices architectures to operate in a secure and reliable way on smaller edge devices. This is accomplished through the use of a type-1 hypervisor, an Edge Container runtime, and a hardened root-of-trust implementation, enabling workloads to run in either a VM or standard container environment. By decoupling software from hardware, EVE also allows for multi-tenant deployments that can operate in complete isolation from each other, increasing security and decreasing complexity.

Key features of Project EVE include:

  • Compatibility with all major edge hardware and cloud providers—no vendor lock-in
  • Ability to support any application that can run in a VM or standard container
  • Simplified application management through standardized APIs
  • Smarter hardware usage through coordinated resource allocation and partitioning
  • Ability to create a zero-trust approach to security, leveraging a hardened root-of-trust implementation

As the number of IoT devices continues to skyrocket, it’s becoming more and more important for businesses to be able to process, analyze, and act on sensor data in real time via local edge gateway systems. Project EVE provides a key component of the technology stack needed for powerful computing at the edge. By contributing the code for Project EVE to LF Edge, ZEDEDA is furthering the organization’s mission to create an open framework for edge computing.

For more information about Project EVE, visit https://www.lfedge.org/projects/eve/.

 

LF Edge at IoT World

LF Edge will be at IoT World 2019 in Santa Clara, Cali. from May 13 to 16. The event is the leading IoT showcase that features the top technologies, strategies, and case studies for the key industries implementing IoT. This year, LF Edge projects Akraino, EdgeX Foundry & Project EVE will be at the show floor to show off their latest demos in booth #610.

Akraino will be on-site to show off it’s it’s latest line of blueprints, which are designed to support a wide variety of edge use cases. Akraino will show off it’s SDN Enabled Broadband Access (SEBA) blueprint, ELIOT (Edge Lightweight and IoT) Blueprint, Micro-MEC Blueprint and the Future Network Lab Connected Vehicle Blueprint. The Akraino community tests and validates the blueprints on real hardware labs supported by users and community members.

EdgeX Foundry will showcase it’s building automation demo, which highlights EdgeX’s ability to bring together a real-world, smart flexible office space environment based on components from a variety of vendors leveraging numerous connectivity standards, operating systems and hardware types.

EdgeX will also be featured in a demo from Beechwoods Software that showcases the AMD Edge Gateway reference running EdgeX and supporting IBM Watson IoT for both the cloud and the analytics engine.

In addition, Project EVE will also be on the scene with its new wind turbine model. Based on the EdgeX framework and the Project EVE technology, the demo will showcase turbine  operations analytics.

LF Edge members will be also be on-site to provide background on any of the projects or walk you through an interactive demo. Stop by booth #610 to learn more or attend any of the following IoT presentations on Thursday, May 16:

  • Jason Shepherd, LF Edge Governing Board Member and CTO of IoT and Edge Computing at Dell Technologies, will present a session at 11:40 am – Noon in Grand Ballroom F. The presentation titled, “The Holy Grail for Digital & Data,” explores where companies are today with their data strategy and where they might be in five to ten years.
  • Arpit Joshipura, GM of Networking & Orchestration + Edge / IOT at the Linux Foundation, will present on a panel titled “The Fast and The Curious: Smart, Safe Ways to Accelerate Building and Deployment,” at 1:40 pm – 2:20 pm in Grand Ballroom G. He’ll be joined by Frederic Desbiens,  IoT & Edge Program Manager at The Eclipse Foundation, Christopher Konopka, Developer Evangelist at Twilio & Brian Buntz, Content Director at IoT World Today. Attendees of this session will learn about the latest methods for bringing a commercial or in-house IoT application or device into production more quickly, efficiently and securely.
  • Arpit Joshipura will then join Sue Troy, IoT World Today Executive Editor and Alexander Olesen, Founder of Babylon Micro-Farms, for the last panel of the day titeld, “What’s the deal with…?” From 4:20 – 5 pm in the Grand Ballroom G, the panel will discuss  new IoT technologies, projects, hardware, software and services and a wide range of other topics like edge and IoT, starting an IoT company , 5G, WIFI 6, digital twins, challenges and concerns.

If you have questions or comments, visit the LF Edge Slack Channel and share your thoughts in the #community or project channels.

EdgeX Foundry Is a Finalist for The IoT World Awards

EdgeX Foundry, the vendor-neutral, operating system and hardware independent, open source, microservice, software edge computing platform, is a finalist for the “Best Edge Computing Solution & Achievements in IoT Integration” award for the IoT World Awards. The awards celebrate the success and outstanding contributors to the very best in the world of IoT.

Other finalists in this category include Dell Technologies and FogHorn – both are currently LF Edge members and are still very active in EdgeX Foundry – as well as Itron Inc and Lantronix Inc.

Not only will EdgeX Foundry be attending the award celebration but will be on-site on the exhibition floor. To see interactive EdgeX Foundry demos, which include building automation and a wind turbine, visit the LF Edge booth (Booth 610). For more information about the activities planned for IoT World, visit https://www.lfedge.org/event/iot-world-2019/.

EdgeX Foundry focuses on IoT Edge, and helps simplify the process to design, develop and deploy solutions across industrial, enterprise, and consumer applications. Since it’s launch in 2017, EdgeX has met several technical milestones in its roadmap including the Barcelona release, California release, & Delhi release.

In January 2019, EdgeX Foundry joined Akraino, Project EVE, The Open Glossary of Edge Computing and Home Edge to form LF Edge, an umbrella organization dedicated to establishing an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating systems.

The winner of the award will be announced at the IoT Awards Dinner & Gala in Santa Clara, CA on May 15. To learn more about the awards or any of the other categories, click here.

Arm at the Edge: Telco and IoT Akraino Blueprints debut at ONS 2019

By Tina Tsou, co-chair, Akraino Edge Stack Technical Steering Committee & Enterprise Architect, Arm. A version of this post also appeared on the Arm Community blog

Last week at Open Networking Summit in San Jose, there was a lot of buzz about the Akraino Edge Stack Project. Launched in 2018, Akraino Edge Stack was developed to create an open source software stack that supports high-availability cloud services optimized for edge computing systems and applications.

Significant progress has been made in this community since the launch, and many member companies showcased their Akraino blueprints last week. Arm is very active in the Akraino community and is excited about the Akraino Edge Stack Blueprints.

Here are some additional details about the four blueprints that were shown:

1) SDN Enabled Broadband Access (SEBA) on Ampere-based servers

For users of Virtual broadband access (XGS-PON which is a higher bandwidth, symmetric version of GPON), Ampere demonstrated SDN Enabled Broadband Access (SEBA) validation on Arm. The SEBA blueprint in the Akraino Edge Stack Project, can run applications of Virtual broadband access – vOLT access and aggregation for 5000 edge locations. There are three servers per POD, with x86 and Arm (with 8-16 cores each). The power consumption is restricted to less than 1 kW and includes NEBS compliance and 48V DC. The Ampere eMAG-based server delivers competitive performance per watt with 32 Armv8 CPU cores at 3+ GHz with Turbo. 

The foundation of the SEBA validation on Arm demo is built on Integration Edge Cloud (IEC) blueprint family. The Integrated Edge Cloud (IEC) enables new functionality and business models on the network edge with benefits such as lower latency for end users, less load on the network since more data an be processed locally, and full utilization of the computational power of the edge devices.

VMWare proposed multi-cloud xConnection to interconnect different kinds of clouds of IT and Telco. The IEC had several deployment models that each support different business case such as telco/enterprise edge cloud (ex. MEC or brand office data center) or telco/enterprise remote edge locations (ex. SD-WAN, IoT Gateways). The demonstration included Ubuntu, Kubernetes, and Calico on Arm.

2) ELIOT (Edge Lightweight and IoT) Blueprint on Huawei IoT Gateway 

We were excited to partner with Huawei to demonstrate the ELIOT: Edge Lightweight and IoT Blueprint Family.  The ELIOT blueprint was designed to service the need of many diverse business applications that require a converged IoT gateway, and Enterprise WAN edge use of SD-WAN solutions or universal CPU (uCPE). The IoT gateway can be deployed in smart cities, smart homes, connected farming, agriculture logistics industrial, and Industrial IoT.  SD-WAN, WAN edge, uCPE are designed to be used for hybrid WAN, hybrid cloud deployment, and BYOD.  ELIOT is very scalable, from 1 single unit to 10K, 100K, 1000K, or more. ELIOT also supports diverse types of edge applications in many industries and market segments, including but not limited to: telcos, operators, service/cloud providers, medicine, smart cities, industrial IoT, home, and enterprise. The cloud/network infrastructure for ELIOT includes containers, Kubernetes, and the Kubernetes ecosystem. At the same time, the blueprint is designed to use lightweight operating systems and container runtime environments.

“The IoT gateway and enterprise edge SD-WAN gateway are two great examples of computing or power resource constrained edge nodes. The ELIOT project provides end-to-end light-weight open source blueprints for deploying and managing these use cases, built on any processor architecture, to foster a vibrant ecosystem around edge gateways in both hardware and software.”

–  Bill Ren, Chief Open Source Liaison Officer, Huawei

3) Micro-MEC Blue Print from Nokia

Nokia, Arm, and other ecosystem partners within the Akraino/LF Edge community have formed an edge blueprint for a Smart Cities platform called Micro-Mec (uMEC) targeted for a range of use cases. Nokia is using an Arm-based Marvell CN83xx uMEC design to show a highway traffic monitoring application. The uMEC enables new functionalities and business models on the network edge. The benefits of running applications on the network edge include lower latencies for end users, less load on the network since more data can be processed locally, and better security/privacy since sensitive data need not be transferred to a centralized location.

All these new services support the business case for building new high-speed networks which in turn enable new things. The uMEC has several deployment models that each support different business cases including:

  • Fixed installation as part of 5G NR base station enabling new services that require low latency such as AR/VR.
  • As an extension of the previous, the “Smart City” deployments have additional functions such as weather stations, cameras, displays, or drone charging stations.  The control software for these functions would run on the uMEC.
  • In an Industry 4.0 use case set, the uMEC is deployed as part of a 5G network and would provide a platform for running services for the factory floor.
  • In a train, the uMEC could collect and store surveillance camera data for later uploading. 

“Nokia is very excited to demo the the new edge blueprint for operators and smart cities called Micro Multiaccess Edge (uMEC). It demonstrates how even a very small ARM- based system can implement a Smart City use case, and complements the industry standard Open Edge hardware that is used in the Radio Edge Cloud and the 5G Radio Access Network,” said Tapio Tallgren, Project Technical Leader for uMEC and Akraino Technical Community

4) Tencent Future Network Lab Connected Vehicle Blueprint

The Connected Vehicle Blueprint focuses on the MEC platform, which is the backbone for V2X (Vehicle to Everything) applications. The blueprint can be used in multiple use cases, including but not limited to: 

  • Accurate Locations: The blueprint is designed to deliver more than 10X finer granularity in location. GPS is 5-10 meters level location which can be improved to <1 meter.
  • Smart Navigation: Real-time traffic information update reduces the latency from minutes to seconds to provide the more efficient path for drivers.
  • Safer Driving: Insight into potential risks which can’t be seen by drivers’ eyes.
  • Reduced Violation in Traffic Rules: Let the driver understand the traffic rules in some specific area.  For example, change in lines for an upcoming and narrow street, avoiding opposite way drive in the one way road, and avoiding carpool lanes for a single driver.

The blueprint can be flexibly deployed in multiple environments, including bare metal, virtual machine, and container based on commodity hardware (Arm/x86 server). The major software component of this blueprint is Tars, a Linux Foundation microservice Framework project. Tars can be deployed in Arm and x86 servers.  For more detail information for Tars, refer to the github link.

Learn more about connected vehicle blueprint on Google Drive or read the blog post here

“Tencent continuously promotes network innovation from various application perspectives. We believe that application-based network innovation promotes a stronger ecosystem, which brings tremendous benefits to our customers and stakeholders.” –– Zhang Yun Fei, Director of Future Network Lab, Tencent

“Open source is an important technical strategy for Tencent. As both a platinum member and board member of the Linux Foundation, Tencent continuously makes contributions to the Linux Foundation and its projects. After the Tars project contributed to the LF in 2018, and recent Akraino blueprint, Tencent will continue to contribute several new open source projects focused on cache and configuration. We welcome additional participation from more Linux Foundation member companies!” — Xin Liu, Linux Foundation Board member, and Tencent General Manager

We are excited about these great Blueprint demonstrations and the others shown last week. I want to acknowledge the Akraino Edge Stack Project Technical Steering Committee, PTLs, committers, and contributors, for their support with our activities at the conference.  It is truly a team effort! Special recognition goes to:

  • Aaron Byrd, AT&T
  • Matt Taylor, Ampere
  • Trevor Tao, Arm
  • Gabriel Yu, Huawei
  • Tapio Tallgren, Nokia
  • Robert Qiu, Tencent
  • Xinhui Li, VMware
  • Ken Yi, DiDi
  • Wenhui Zhang, PSU

Connected Vehicle Blueprint Debuts at ONS NA 2019

The  Connected Vehicle Blueprint, established within the Akraino community by contributions from Tencent Future Network Lab, Arm, Intel, and Nokia, was demonstrated onsite at Open Networking Summit this week in San Jose. The blueprint demo clearly depicts features, architecture as well as the potential benefits for customers. The Connected Vehicle Blueprint focuses on the MEC platform, which is the backbone for the V2X (Vehicle to Everything) Application.

The blueprint can be used in multiple use cases, including, but not limited to:

  • Accurate Location: The blueprint brings more than 10X fine gratuity location. GPS is 5-10 meters level location, that can be improved to <1 meter, which is the distance of a typical street lane.
  • Smart Navigator: The real-time traffic information update, reduces the latency from minutes to seconds, figures out the most efficient route for drivers.
  • Safe Drive Improvement: Helps the driver figure out any potential traffic risks that may not be seen by the driver.
  • Reduces traffic violations: Helps the driver understand local traffic rules. For instance, changing the lane prior to a narrow street, avoiding driving on the wrong side of a one-way road, avoiding carpool lanes as a single driver, etc.

“Tencent continuously promotes network innovation from various application perspectives. We believe that application-based network innovation promotes a stronger ecosystem, which brings tremendous benefits to our customers and stakeholders,” said Zhang Yun Fei, Director of Future Network Lab, Tencent.

“Open source is an important technical strategy for Tencent. As both a platinum member and board member of the Linux Foundation, Tencent continuously makes contributions to the Linux Foundation and its projects. After the Tars project contributed to the LF in 2018, and recent Akraino blueprint, Tencent will continue to contribute several new open source projects focused on cache and configuration.  We welcome additional participation from more Linux Foundation member companies!” said Xin Liu, Linux Foundation Board Member and Tencent General Manager

The blueprint can be flexibly deployed in multiple environments, including bare metal, virtual machine and container-based environments on commodity hardware. The major software component of this blueprint is Tars, a Linux Foundation microservice framework project.  For more detail information on Tars, refer to the link:  https://github.com/TarsCloud/Tars

For more information regarding the connected vehicle blueprint, refer to:

EdgeX Foundry is now available as a Snap

Tony Espy, EdgeX Foundry Technical Steering Committee Member & Technical Architect – Devices & IoT at Canonical, gives details on the recent availability of EdgeX Foundry in snap format. The new availability gives millions of Linux users and developers access to the continuously growing Snap Store.

EdgeX Foundry is a vendor-neutral open source project that concentrates on building a common framework for IoT edge computing. With a focus on the IoT Edge, EdgeX simplifies the process to design, develop and deploy solutions across industrial, enterprise, and consumer applications. Since it’s launch in 2017, EdgeX has met several technical milestones in its roadmap including the Barcelona release, California release, & Delhi release.

In January 2019, EdgeX Foundry joined Akraino, Project EVE, The Open Glossary of Edge Computing and Home Edge to form LF Edge, an umbrella organization dedicated to establishing an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating systems.

In adopting the universal Linux app packaging format, EdgeX Foundry will make its IoT Edge platform available to an ever-growing community of Linux developers, including those on Debian, Fedora, Manjaro, OpenSUSE, Zorin and Ubuntu. Automatic updates and rollback capabilities are staples of snap software, meaning EdgeX Foundry users will always have the best and latest version running.

Snaps are containerised software packages, designed to work perfectly and securely within any Linux environment; across desktop, the cloud and IoT devices. Thousands of snaps have been created since the first one in 2016. EdgeX Foundry joins Plex, Spotify, Skype, and Slack, who have all benefited from snaps’ update and security features.

“Canonical’s Snap Store provides an easy and secure way to distribute our software to an increasing number of developers and users,” said Jim White, Vice Chair – Technical Steering Committee at EdgeX Foundry. “What’s more, snaps help cater to EdgeX Foundry developers, who benefit from snap confinement, binary delta downloads, ease of deployment/configuration, and sophisticated service management.”

The EdgeX snap is fully confined, which means snapd ensures that applications and services provided by the EdgeX snap may only use hardware and system resources that have been explicitly granted to the snap. Binary delta downloads is a feature which benefits users of snaps by lowering the bandwidth required for software updates. Ease of deployment/configuration stems from the fact that the snap provides all of the EdgeX reference services as a single package. This makes it trivial to build an appliance-like image using the EdgeX snap with Ubuntu Core.

Finally, it also should be noted that all of the EdgeX reference services in the snap are deployed as system services. This ensures that EdgeX will be automatically started when a device boots, services can be individually managed (i.e. enabled/disabled/started/stopped/restarted), and services will be automatically restarted by the system if they exit due to an error condition.

For more details on how to use the EdgeX Foundry snap click here. EdgeX Foundry is available to download as a snap by clicking here.

This blog originally ran on Canonical’s Ubunto blog. You can view the blog here.

An Enhanced Delhi Code with More Bells and Whistles

A few weeks back, the EdgeX Foundry community released Delhi.  This release (the third public major release of EdgeX in a little more than a year) included many new features and I outlined them in my last blog post . Today, the project announced the availability of an enhanced Delhi release, with a smaller collection of new and updated capabilities built on top of Delhi.  

The Delhi code release offers so many new features, I’m not going to list them all. Instead, I’d like to focus on what’s new with this enhanced Delhi release.  In particular, the enhanced version of Delhi begins to allow for freedom of choice with regard to databases in EdgeX. With this release, several of the services (core data, metadata and export client specifically) have been engineered to use either MongoDB (the long used default persistence for EdgeX) or Redis. This improvement to the EdgeX platform is significant for several reasons:

  • It highlights the ability for organizations to select and more easily use the data store that best fits their use case and system needs.  Platform support, performance characteristics, licensure issues, in-memory options, etc. are all architectural considerations when looking at persistence in your IoT platform.  
  • It is the first step in providing proper abstraction and loose coupling around the persistence layer.  Eventually, this work which we hope will be completed for the Edinburgh release (April 2019) will allow architects more freedom to customize, extend, and replace this layer based on their persistence needs.
  • EdgeX is all about providing interoperability, flexibility and facilitating choice at the edge – choice in sensor connectivity, analytics, cloud connectivity, deployment, etc. This new feature again showcases EdgeX’s flexibility – flexibility in persistence realm.  Future releases of EdgeX, using patterns established with this database abstractions, are looking at offering even more flexibility and interoperability in areas like messaging, security, communications, system management, etc.

The EdgeX community (which includes members of the Redis Labs team) worked throughout the Delhi release to simultaneously refactored several of the EdgeX microservices to offer Redis as embedded data services.  Specifically, this means we:

  • Incorporated the EdgeX services with the tools needed to connect to databases such as Redis and MongoDB
  • Leveraged Redis’ multi-model capability and data structures to serialize EdgeX data models for persistence, and index them for queries
  • Decoupled the EdgeX models from a single persistence mechanism
  • Solve identity issues, such as identifying sensor readings, in a database-independent way
  • Added Redis to the EdgeX deployment/orchestration facilities
  • Provided Redis initialization and bootstrapping scripts in support of EdgeX

Again, all of this work is important first steps toward more unilateral independence and choice with regard to persistence in EdgeX in future releases.

In addition to the work to provide alternate database connectors in several key EdgeX microservices, the enhanced Delhi code will also include the following:

  • New device service connectors, created from the new SDKs made available for Modbus and MQTT.  These were device services created with the new Go and C Devcie Service SDKs that were made available with the Delhi release.  Device connectors provide the “thing” or sensor/device connectivity in EdgeX.
  • A simple example device service simulator that developers can use to learn the EdgeX device service framework and speed up their development efforts.
  • Additional and improved documentation that includes all the new features from the Delhi release.
  • The EdgeX Foundry snap published in the the Snap Store (https://snapcraft.io/edgexfoundry) for the first time.

It should be mentioned that with the new Device Service SDKs, we are seeing a real escalation in EdgeX “thing” connectivity.  As I write this post, several additional Device Services have been created beyond what is offered in the “dot” release. So stay tuned to the EdgeX community outlets for more in this area coming soon.

Big shout out to the technical community for helping us achieve another technical milestone To learn more about the Redis connection, please click on this blog.

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel.

ETRI unveils Time-Sensitive Networking IIoT Gateway based on EdgeX

Guest post written by Geun-Yong Kim, EdgeX Foundry member and Researcher at ETRI

EdgeX Foundry member, ETRI (Electronics and Telecommunications Research Institute) exhibited the EdgeX-based gateway system at the 2018 Photonics Convergence Industry Road Show held in Gwangju, Korea, on November 20- 21, 2018. The Photonics Convergence Industry Road Show is an annual event that companies related to Korean photonics convergence showcase their products and technologies, share best practices and build a stronger network.

< ETRI booth at 2018 Photonics Convergence Industry Road Show >

ETRI’s Time-Sensitive networking IIoT gateway is based on the Go version of the EdgeX framework. It is equipped with hardware that can install a device module with legacy device interface such as RS-232/485, Modbus, etc. It also provides time synchronization accuracy of less than 300ns error for Time-Sensitive Networking, which is a new Ethernet standard that guarantees bounded latency of data transmission.

< ETRI TSN IoT Gateway collecting measured data from BMT Smarteye sensors>

Since BMT gateways collect data sequentially from Smarteye sensors, there was a limit to the data analysis. Therefore, ETRI developed the device that can acquire data from multiple RS485 interfaces at the same time and implemented a new Device Service of EdgeX Foundry to handle it. The ETRI gateway is able to collect 27 kinds of data from BMT Smarteye power measurement sensors. It also collects measured data from three Smarteyes simultaneously per second and the demo included collecting data, exporting data, and rules detecting from data.

Additionally, ETRI developed GUI optimized for EdgeX micro service structure, and users can easily install and delete micro services for gateway by GUI. ETRI has also developed the TSN micro service, rules engine for analyzing power measurement data for TSN networking function, and implemented the GUI to visually express data flow between micro services.

< Micro service management GUI >

< Data collection and graph from BMT Smarteyes >

ETRI will continue researching and developing industrial IoT gateways for the renewable energy industry and power utility sectors based on the EdgeX Foundry framework. For more information, you can email Geun-Yong Kim at gykim@etri.re.kr. 

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel.

EdgeX Foundry Releases Delhi and Plans for Edinburgh

The technical details on the current and next release of EdgeX Foundry

Jim White, Dell Technologies IoT Platform Development Team Lead & EdgeX TSC Vice Chair

This week, EdgeX Foundry announces the release of Delhi, our third major release in 12 months.  With each release that this growing community kicks out – I get a little nostalgic.  EdgeX started its life in my kitchen.  Like a lot of open source software efforts – it started humbly.  In the case of EdgeX, it started on my laptop, propped open on my kitchen island one summer weekend about 4 years ago with an adult beverage or two.

Today, Edgex is being developed around the globe by a lot of tremendous software engineering talent.  I was proud to start EdgeX, but I am even more proud to be part of an exciting group of international engineers building the most flexible, interoperable, open source IoT platform on the planet. This new release, Delhi, contains a new service and several key features that have our community and potential customers excited about the future of EdgeX Foundry.

Delhi Release

System Management

Most importantly, this release contains the first EdgeX system management capability.  A new service – the System Management Agent (SMA) – serves as the coordinator for control plane information (status, configuration and metrics around EdgeX services) and control actions on EdgeX services (start, stop, and restart).  Cloud or third party systems can call on the API provided by the SMA to trigger the actions or to get the control plane data they need. The SMA can serve as a one-stop shop for managing an instance of EdgeX.  Each EdgeX micro service has a corresponding management API that the SMA calls on to help control that service (example – stop the service) or pull back its latest configuration or metrics.  The SMA and management API provided by each service will be expanded in future releases of EdgeX and will one day offer control plane data and actions via alternate protocols (like LWM2M or SNMP).

Device Service SDKs

The original platform that started on my kitchen island was a Java platform.  Last year, the community embarked on an endeavor to replace the bulky and slow Java services and tools with Go and C services and tools.  Device Services – the EdgeX services that connect “things” to the platform are still in Java but not for long.  With the Delhi release, two new Device Service SDKs have been created.  The Go and C SDKs are allowing the community to create smaller, lighter, faster device/sensor connecting services that will allow EdgeX to operate in very limited resource compute environments – the thin edge in IoT solutions.

Improved Service Resiliency and Decoupling

In the past, the EdgeX microservice dependencies required the services be brought up with wait times between the startup of each service to allow the system time to bring things up in order.  The services now are able to automatically check and detect when a dependent is in place and to become fully functional only after a dependent is up.  This greatly reduces the start of all of EdgeX from minutes to seconds – around 5-10 seconds on average.  The services now detect a dependent has gone down and will keep retrying that service until it comes back up.  This gives EdgeX more resiliency than it had in the past.

EdgeX User Interfaces

EdgeX was built to facilitate machine to machine communications.  As such, it did not have a user interface.  With the Delhi release, user interfaces were created – largely to help visually showcase EdgeX functionality and to help developers – these UI also serve to show how EdgeX can be driven and operated.

Improved Core and Supporting Services

Many of the core and supporting services in EdgeX were improved and more unit testing was added to allow the community to keep an eye on the quality of the overall system and compatibility of future features of EdgeX.  The Scheduling Service was also transitioned from Java to Go.

More Secure

Security services were initiated in our last release (California).  The Delhi release includes the next wave of security features such as access control to grant access to appropriate services, and improved security service bootstrapping.

Better Tested

As mentioned, more unit tests were added to the EdgeX services.  Additionally, automated blackbox tests are in place for each service to make sure the public API of each service performs as documented.

Ecosystem Growth

In addition to all this hard work, our EdgeX Foundry ecosystem continued to expand during this release cycle.  Among the new companies to join EdgeX Foundry are Basking Automation, Data Ahead, Intel, Redis Labs, and ZEDEDA.  This community also launched the availability of a developer kit and community demonstrator (for showcasing EdgeX during conferences and IoT events).  Find out more about these here.  Stay tuned to the EdgeX news and announcement pages as some big organizations are preparing to announce their joining early in the New Year.

Edinburgh

OK – no time to rest on our laurels.  What’s next EdgeX?  I am glad you asked!  Indeed, the EdgeX technical steering committee (TSC) along with several community members met in Edinburgh Scotland to plan and scope our next release – code named Edinburgh – which is scheduled for April 2019 (I assure you the release name and TSC meeting place alignment happened a little serendipitously).

As Keith Steele, Chair of the EdgeX Foundry Technical Steering Committee, reported in his blog post, the results of the meeting were “superb” – as the Scots like to say.

The Edinburgh release has been scoped to include a rather significant amount of new features as well as making improvements on the current code base (“cleaning up technical debt” as we like to say).  Given the increase in community membership and number of contributors to the project, we feel this scope is within reach.  Here are some of the major efforts the membership has planned for the next 5-6 months.

Binary Data Support

The Edinburgh release of EdgeX will support the ingestion, use, and export of binary data (using CBOR format).  To date, EdgeX has supported ingesting, using and exporting integer, float, string, and boolean types of discrete data collected from sensors.  Many of the edge use cases involve video images, audio data, and other data that is binary data serialized.

Automated Performance and Security Testing

EdgeX has come a long way over the past few releases in increasing and improving its quality through testing.  In the Edinburgh release, performance and security testing will be automated.

Cornucopia of new Device Services

The new Go and C Device Service SDKs created with the Delhi release allow the community to create smaller, faster, less-resource consuming replacements for the Java Device Services that now serve to connect “things” to EdgeX.  This includes Modbus, BACNet, BLE, MQTT and SNMP Device Services.  As there has been a bit of a pent up demand to get new Device Services for EdgeX due to the development of the SDKs, we believe this release will contain even more thing connectors than we could have imagined a year ago.

The paint on the new SDKs isn’t even dry and we already have the community showing off some early prototypes of new Device Services today and the numbers are impressive.  In one small example, our old Java Modbus Device Service was 141MB in size and consumed 184MB of memory.  The Go version produced with the new SDK is 16MB in size and uses just 8MB of memory.

Application Services

The current EdgeX Export Services, while functional, create scalability issues. The current EdgeX capability relies on the Export Services to know and understand all possible endpoint distribution mechanisms and transformation capability necessary to support all clients – even if the use case requires only a single, simple client (like sending the raw sensor event data to an MQTT pipe in JSON). As the number and type of EdgeX north side clients (cloud, enterprise and on-prem IoT servers) expands, this service will be too big and complex to support the north side needs.

The Edinburgh release will feature a new type of “exporting” service – the Application Service.  The initial and simple Application Services in the Edinburgh release will be designed and implemented to support smaller, more tailored exportation needs. These services will contain just the functionality (filtering, transformation, enrichment, etc.) needed for a single endpoint. To address multiple endpoints, multiple Application Services will be created (versus having one massive export service as EdgeX has today). In a way, the Application Services will begin to look more like the south side Device Services – that is functionality dedicated to a particular client protocol and data need. Long term over the course of a number of releases, Application Services will replace EdgeX Export Services as the north side distribution facility.

Improved User On-boarding & Support Plan

EdgeX Foundry has been a developer driven effort.  As the platform is and will continue to be used in real world IoT solutions, it becomes imperative that the community improve the quality and volume of documentation, tutorials, examples, videos, etc. to help user communities go from day 0 to production as quickly as possible.  It is also imperative that EdgeX institute a long term support plan/strategy to give the user community assurances about what they can expect from the open source effort they put into their products.  The TSC Chair (Keith Steele) and TSC Vice-Chair (me) are dedicating our resolve to address these two concerns as part of the Edinburgh release cycle.

Certification Program

A certification program will be outlined in concert with the Edinburgh release. A certification program will enable third parties creating EdgeX services to verify their services as alternative or enhancing capability to those provided by the EdgeX open source effort.  This will allow 3rd parties to add value (proprietary or open source) to EdgeX that customers can rely on to meet the EdgeX APIs and work without additional code change (enabling a plug-and-play ecosystem).  Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX).  Additional certification processes may be developed around particular cross cutting features such as security.

And More…

  • Use of Vault namespaces for storing secrets for the micro services.
  • Initial EdgeX secrets (needed to start Vault/Kong) will be encrypted on the file system using a secure storage abstraction layer – allowing other implementations to store these in hardware stores (based on hardware root of trust systems)
  • Refactor EdgeX database-using services (Core Data, Metadata, Export Client, Logging, Notifications, and Scheduling) to be more loosely coupled to the persistence mechanism (currently MongoDB). This will better facilitate the use of alternative persistent stores and technology in future implementations and even allow the project to select alternate or additional reference implementation databases in future releases.
  • A smaller, lighter, faster rules engine service to replace the last of the EdgeX Java micro services.
  • System Management will offer service health/status checks and additional metrics
  • Updating the versioning and dependency management system for all Go micro services (replacing a deprecated technology)
  • Upgrading all 3rd party open source tools included with EdgeX (Consul, Kong, Vault, etc.) to use the latest releases

For a full list of the Edinburgh release scope and roadmap, see the project Wiki.

It’s a large scope, but the community and team of developers is growing.  Contact our Developer Advocate, Michael Hall, if you and your team would like to be a part of our effort – it’s an exciting time to be part of an exciting and industry impacting project.  I have every confidence the EdgeX Edinburgh release will make some news in April 2019… as long as I can keep the team away from all the Scottish whisky we brought home from our trip!

2 Great Weeks in the Life of EdgeX Foundry

By Keith Steele, Chair of the EdgeX Foundry TSC

I wrote this blog on a train from Edinburgh back to my home town in Newcastle UK, ending two weeks of spirited activity for the EdgeX community. On October 15-17, we gathered in Barcelona for IOT World Solutions Congress and then we met in Edinburgh for our bi-annual Technical Steering Committee (TSC) meeting.

Both weeks were by hugely successful for the project with some major milestones achieved, market momentum demonstrated and collaboration that solidified plans for our impressive roadmap, which agreed for the next EdgeX release in April.

Most striking of all, however is the growing ecosystem of contributors driving the project forward, their talent, enthusiasm and unselfish collaboration. It was just a pleasure to witness and a lot of fun – I’ll never quite forget the gradual rise in volume in the room as we progressed through the Scotch Whiskey tasting with the TSC!

Anyway, I digress, let’s start this blog in Barcelona, or for some of us Toulouse! The IOTech team had a slight travel diversion due to storms and ended up in nice Southwestern French city, but didn’t get to explore. Undeterred, the team developed an alternate travel route and finally showed up in Barcelona to see the EdgeX Foundry booth ready and looking sharp with the new community demo as a nice focal point.

The New Community Demo

EdgeX Foundry’s new community demo set out to demonstrate the full capability of EdgeX in the context of a realistic use case, we chose Buildings Automation but it could have been any edge vertical. When we say the full capability of EdgeX we mean:

  • Multi vendor, multi protocol southbound connectivity and data interoperability – the demo has over a dozen different connected devices seamlessly interoperating through EdgeX using standard connectivity software!
  • Hardware independence – the demo has three gateways from three different vendors hosting EdgeX, demonstrating its distributed microservice capability
  • Silicon provider independence – three Gateways, three different chip sets; 32 and 64 bit ARM and 64 bit Intel
  • Application plug and play – standard Microservice API’s enabled easy replacement of the EdgeX rules engine reference implementation with NodeRED to demo Edge analytics capability
  • Local Edge Control – the demo is not just about collecting data, it shows full the full command capability of EdgeX
  • Connect to any Cloud – the demo shows connectivity to AWS but this could just as easily have been Azure, Google, or any cloud
  • Interaction with Cloud Applications – in this case, we showcased higher level Energy Management and Space optimization software interacting with the Edge system but with flow of data filtered and optimized to cut expensive cloud data usage costs!

If you weren’t at the show, you’ll be able to see a video of it soon. In the meantime, James Butcher, Senior Solutions Architect at IOTech, shares the details of how the demo came together in this blog post.

So, how was it all received?

I say without hesitation this was a great show for EdgeX (and I say this as someone who usually regards trade shows as only marginally more useful than a Celine Dion tribute act).

The EdgeX Foundry stand was continuously busy – attendees came to see the community demo and meet with EdgeX members Basking Automation, CloudPlugs, Dell, Enigmedia, IOTech, and Mainflux as well as Redis Labs, RSA, VMware and ZEDEDA with their own presence demonstrating their integration with EdgeX.

At the show, we announced Intel and eight other tech influencers joined the project and there was huge interest for this and the new EdgeX dev kits at the show. Jason Shepherd, Chair of the EdgeX Foundry Governing Board, and I were busy briefing customers, analysts and media, while traffic to the booth was heavy and constant. James, one of the people manning the community demonstrator only managed lunch at 4pm the 1st day of the show!

My own takeaways

Barcelona, for me, proved without a shadow of doubt an open approach at the Edge is now a well-established need and EdgeX is regarded as the leading open implementation.

The vendor neutral approach is the clear driver, the Edge is by its nature a very heterogeneous and users want a solution that is designed to support that heterogeneity rather than a proprietary solution that locks them in to a specific vendor.

The flexibility of choice of cloud and hardware providers were big winners with visitors to the EdgeX booth. Some of the bigger users are hedging their bets with dual approaches, but there was evidence from the many vendors visiting the booth that they recognized they were going to have to support EdgeX.

Another big motivator was an open approach as a basis for bringing together the 6-10 vendors/technology partners typically required to deliver an end to end IOT solution using EdgeX as an integration point allowing vendors to keep their proprietary value add while collaborating across a standard and open infrastructure. Interesting times!

On to Edinburgh for the EdgeX Technical Steering Committee meeting.

Good to see the numbers growing with 40-50 people attending across the 3 days of the meeting, again from all corners of the globe. Nice to also to see many new faces from Intel, Siemens, Thales, Analog Devices, Canonical, Dell, ForgeRock, Intel, IOTech, Mainflux, Redis Labs, Samsung Electronics, Siemens AG, Technische Universität Berlin, University of Edinburgh, VMware, and Wanxiang Group.

The main meeting discussion topics were the roadmap for the next release, called ‘Edinburgh’ (scheduled for release in April 2019) and the status of the Delhi release, which we just announced the code freeze with release in mid-November.

The Delhi release is a very important milestone for EdgeX as the core services have now all been refactored in Go and C providing a big improvement in performance, footprint and scalability.

A dot release to Delhi is going to be released in December to provide Redis as the underlying database option (in place of MongoDB) for several services including Core Data, Core Metadata and Export Client.  This work will be even more of a focus for Edinburgh where the easy replacement and swap of databases that support EdgeX is desired.

In parallel to the formal Delhi release of EdgeX, several community developer kits will also be made available, the first based on the Samsung Pi and Artik developer boards (link). The dev kits will go a long way to onboarding future EdgeX developers and improving developer onboarding will be a key priority for the TSC this year.

Here’s a short list of what was scoped for the Edinburgh release:

  • Support for binary data to be processed by EdgeX for the first time to allow for carrying video images, audio data, and the like.
  • Implementation (initial) of Application Services, an eventual replacement for Export Services, will be more scalable and functionally driven microservices for getting data from EdgeX to other systems and applications.
  • Definition for how EdgeX will operate on top of hardware root of trust systems and take advantage of the secure storage with an abstraction layer
  • Performance targets for EdgeX are already being hit, but performance testing as part of the continuous integration and release process.
  • Building better abstraction and separation of concerns around persistence for the services using a database (MongoDB today) in order to allow easy replacement of the database in the future.
  • Implementing the next wave of system management features to include providing more service metrics and offering EdgeX metrics, configuration and status information via additional control plane protocols (such as LWM2M, SNMP, etc.).
  • Adding a plethora of Device Services (DS) for various protocols given the new DS SDKs in Go and C.

Look for a future post by Jim White, our EdgeX Foundry Vice Chair of the TSC, to provide more details on the upcoming April 2019 release.

A few other points of notes from the meeting

We agreed it was time to have a release manager to oversee the bi-annual EdgeX releases and this task would be undertaken by the major contributors. Ideally, we’d rotate ownership of this task and it would be a good way forward with potentially 4-member companies taking it in turns by rotation. A call will be set up shortly to discuss this process and move forward with it.

The DevOps and QA/Test Working Groups will, for the next few months, run combined calls given the close cooperation needed and the focus in the EdgeX Edinburgh release on incorporating automated performance and scalability tests as part of the overnight runs. Look out for the new time for these meetings shortly.

Now the C and the GO SDK’s are available a big part of the Device and DeviceSDK Working Group’s work will now switch to acceleration and collaboration around accelerating new Device Service connectivity. This is obviously seen as key to widespread deployment of EdgeX going forward.

As mentioned, we had to have a little bit of fun while in Edinburgh. There’s nothing quite like Scotch Whiskey tasting in Edinburgh.

 

 

Remember, if you can’t make the meetings you can join by phone and the recordings of the meeting can be found here.

The next F2F TSC meeting will be hosted in Seoul, South Korea on April 22 -25.2019. You can register here and find more information is available on the EdgeX Wiki.

It was also announced the October 2019 meeting will take place at Intel’s facility in Chandler Arizona. We look forward to collaborating with you there!!

Finally, a couple of thank you notes, the first one to Jeremy Phelps, who is stepping down as chair from the DevOps Working Group, Jeremy’s enthusiasm, skill and effort levels have been just stellar and he will be a hard act to follow!

Lastly, thanks to the team at the Linux Foundation for their massive efforts in bringing both Barcelona and Edinburgh to fruition with professionalism and untold patience having to deal with me. Maybe next time, we all get an Octopus T-shirt!

Best Regards,

Keith Steele, TSC Chair

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

EdgeX Foundry Member Spotlight: ZEDEDA

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with Joel Vincent, the Chief Marketing Officer for ZEDEDA, to discuss the power of IoT, edge computing, the reason they recently joined EdgeX Foundry and preview the new demo they are debuting at IoT Solutions World Congress in a few weeks.

What does your company do?

Quite simply, ZEDEDA is building an applications services platform for the cloud-native edge. Our vision is to free cloud apps and allow any app to run anywhere on any device. As edge computing expands beyond the constraints of embedded computing, ZEDEDA effectively completes the cloud.

Why is your company investing in the IoT ecosystem?

IoT and the world of Edge Computing is not just expected to be orders of magnitude larger than the cloud itself, it’s going to be a world of inter-networked, multi-vendor, multi-owner, hardware diversity. We haven’t seen anything like this since the advent of TCP/IP itself. How do you get this diverse universe of computing working together to allow businesses to use the edge to evolve?  It’s going to require multi-vendor cooperation, open source efforts, and universal standards built around an IoT ecosystem.

How has IoT impacted your company? What benefits have you seen or what do you expect to achieve?

The forces that made the Internet of Things possible gave rise to the fundamental technologies that made ZEDEDA possible. Compute power continues to shrink in size and cost and increase in capabilities. It was only a matter of time before compute power that was once considered server-class was small enough, powerful enough, and cheap enough to be embedded in everyday devices that even a consumer can afford. That meant a new compute orchestration layer was required. That’s where we came in. In fact, we couldn’t have created ZEDEDA 3 or 4 years ago. Computing technology and IoT have advanced that quickly.

Why did your company join EdgeX Foundry?

EdgeX Foundry represents an opportunity to collaborate with other thought leading companies in edge computing and really make an open edge framework a reality. With a vision of apps running anywhere, on any device, over any network the goals of EdgeX Foundry aligned perfectly with our vision and mission for the future of computing.

How are you going to use the framework?

For us and the orchestration of the edge virtualization requires apps to view, understand, and address hardware in a standard fashion. Initially on of the most difficult things to orchestrate is how an app accesses the hardware resources its running on and with the diversity of hardware a framework defining how resources are handled and abstracting the “sausage making” away from the app development so that any app can address any hardware resource is a major key.

So our first effort, which we are demonstrating at IoT Solutions World Congress 2018 is how to get the EdgeX microservices deployed on thousands of devices that are geographically distributed in a simple, repeatable, and secure fashion. Once enabled, an app build to the EdgeX framework will be able to “work” on the hardware we’ve enabled.

Where do you see enterprise and industrial IoT in 20 years?

You won’t see it. It will just be. Everything will be connected, the cloud will be ubiquitous (seamless between the cloud we know today and the edge that is being built in a standard fashion tomorrow), and from this how we experience the world will be completely different. You will EXPERIENCE IoT in everything you do, but you won’t see a damn thing!

Seeding an Open Marketplace for IoT Edge Computing

Guest post by Jason Shepherd, EdgeX Foundry Chair of the Governing Board and Dell IoT and Edge Computing CTO

Hello Members and Friends of the EdgeX Community,

I hope you’ve had a great summer with friends and family. As we head into some big project announcements at IoT Solutions World Congress (SWC) in Barcelona from October 16-18, I wanted to take the opportunity to make sure you’re aware about a few member opportunities.

First, a quick update on the project momentum. We’re seeing a big ramp in the number of unique code contributors on the heels of the switch to Go Lang for the baseline reference implementation in our recent ‘California’ release. We’re now approaching 70 as of this month. Net-net, more and more people by the day are seeing the benefits of our approach to facilitating greater interoperability at the IoT edge!

As a result, some very large names will be announced as new project members at IoT SWC on October 16. We see many more on the horizon as the word continues to spread and the community meets commitments on delivering a high quality foundation to facilitate interoperability across the complex IoT landscape.

The community has chosen to organize around an October/April semi-annual release cadence, so the Delhi runway is a little shorter. Still, we’re going to see some major enhancements including the first management features, more security enhancements, C and Go Lang-based Device Service SDKs and a reference GUI for demos and simple deployments.

The latest project overview deck including more on progress to date and where we’re headed can be found here.

Other big news at IoT SWC will be the impending release of Delhi code, the launch of our community demonstrator to showcase the value of the project and enable future plug-fests and hackathons, EdgeX developer kits and more Vertical Solution Working Groups (VSWGs). I’ll focus on the latter two for the rest of this project update.

EdgeX-enabled Dev kits

The IoT journey often starts with an aspirational view seeded through a simple PoC to work through architectural and business model considerations before scaling up into deployment. Low-cost developer (dev) kits comprised of a board, collection of pre-integrated sensors and integration with an IoT platform stack are great tools to enable software developers to quickly prototype their ideas with a “fail fast” mentality.

However, the plethora of dev kits out there typically lock the developer into a particular backend platform or cloud. In comparison, kits based on the EdgeX Foundry framework will provide developers with complete freedom of choice, backed by the vendor-neutral EdgeX APIs that bind together choice of devices and applications regardless of protocol, OS, or underlying hardware used.

These dev kits and associated plug-in value-add will give developers confidence that they can prototype with their choice of ingredients while taking advantage of plug-in components from the growing EdgeX ecosystem. And perhaps more importantly, they’ll be able to readily swap out elements later as they optimize their solution and ramp into production and day to day operation.

In all cases these EdgeX dev kits will enable developers to innovate rather than reinvent. The following is a high-level summary of benefits specific to two key personas:

Benefits for end-user developers:

  • Get started developing your IoT solution at a low cost of entry while maximizing options from edge to cloud and minimizing potential for vendor lock-in
  • Facilitate integration and build/buy/partner decisions by tapping into the open ecosystem
  • Have confidence that the foundation of your PoC efforts has staying power due to backing from a growing, vendor-neutral community

Benefits to developers with IoT ecosystem providers (e.g. Device Makers, OEMs, ISVs, SIs):

  • Realize drag from end-user developers earlier in their PoC efforts without having to support myriad custom integrations with your commercial offerings
  • Grow your business faster via the network effect stemming from an open ecosystem with transparent and trusted security and manageability
  • Influence the development of an open commercial marketplace for EdgeX-certified components

More detail can be found in the overview deck. As highlighted, there will be community and commercial tracks for the dev kits. For options in the community track the bill of materials will be purchased independently online, code downloaded straight from a special repository on the project GitHub and questions answered through forums like the EdgeX Rocket Chat. We’re going to start small here and let the open source contributions grow organically.

The commercial track will provide EdgeX members with the ability to seed the emergence of an open marketplace for IoT edge computing. In turn, this will afford end users with attractive options to get started with professional support so they can focus on their preferred value-add instead of working with open source code.

The dev kit program will also help shape the definition of the formal certification program within the EdgeX project targeted for launch with the ‘Edinburgh’ code release in April 2019.  This program will enable anyone to certify that their proprietary offer is “EdgeX-compliant” based on following the specified set of interoperability APIs in Core Services regardless of additional IP added.

 

This is why the project is called “EdgeX Foundry” instead of the obvious “Edge Foundry” – the “X” allows the name to be trademarked. Imagine that “X” on your website which gives your customers comfort that you’re part of a broader, interoperable and trusted ecosystem. Stay tuned for more on this front and we welcome you to get involved in the certification planning working group!

Getting back to the dev kits, there will be several options available to you as a Technology or Services provider in the commercial track:

  1. “Core”: Offered by a provider who’s supporting the baseline EdgeX framework in a ‘Red Hat’ model while ultimately being completely neutral to all value-add such as hardware, OS, connected devices, analytics, security enhancements, platform, cloud, etc.
  2. “Platform”: A kit linked to a specific IoT software platform or cloud, enabling the customer to dive right in with your offer while still being able to take advantage of the ecosystem of plug-in EdgeX value-add
  3. “Plug-in”: Discrete plug-in value-add for devices/sensors, analytics, database, security, management, etc.

The benefit here is the network effect, for example if you offer an IoT platform you don’t need to support the baseline open source EdgeX framework if you don’t want to. Instead, you could partner with a “Core” commercial dev kit provider and simply support an Application microservice for your platform that complies with the APIs in Core Services while leveraging the communication protocol of your choice (standard or proprietary).  In another example, you might be a sensor maker who only supports Device Services in your chosen protocol and programming language (plugging into others’ “Core” and “Platform” dev kits), and so forth.

In order to participate in the dev kit program simply get going with the EdgeX code to develop your offer, establish your preferred commercial terms and contact pr@edgexfoundry.org to let the Linux Foundation team know your plans no later than October 5 if you want to be included in the IoT SWC press release.  More information will be available publicly closer to the announcement.

Note that we’re limiting the benefit of advertisement of commercial dev kit offers through official EdgeX channels to EdgeX project members at this time in order to limit scope while we perfect the process. This ultimately leads to an open commercial marketplace, so get in early and ride the wave!

Vertical Solution Working Groups

The Vertical Solution Working Groups (VSWGs, led by Samsung) are an important function within the EdgeX Foundry project.  We’ve had groups for Smart Factory (Samsung) and Oil and Gas (NOV) for some time to work through the process and are now ready to start ramping more groups to accelerate the strong foundation we’ve built to date. The VSWGs serve several important purposes:

  • Developing unique requirements and code contributions for their respective markets
  • Feeding requirements back into the EdgeX core working groups to optimize the baseline framework to be suitable for as many use cases as feasible spanning Industrial to Enterprise to Consumer, including B2B2C crossover in the domains of retail, healthcare, insurance, utilities, etc.  After all, the true promise of IoT is bringing together a system of systems, and what better way to span private and public domains than an open interoperability framework!

We welcome any member to volunteer to lead a new VSWG or join one already in flight. It’s a great way to demonstrate thought leadership while making sure the EdgeX foundation has the right features and specific extensions for the verticals and use cases that matter the most to you.

We’ve talked with members that are considering working groups around Buildings, Retail, Transportation, Healthcare, Smart Cities and Smart Homes so if any of these areas or others interest you, join on in, or create one for another domain! It’s a low time commitment to help speed up time to revenue in your respective space, not to mention learn from and influence others focused on the same space through open, vendor-neutral collaboration.

To learn more or start a new VSWG please email EdgeX-TSC-Vertical-Solutions@lists.edgexfoundry.org.

Exciting times ahead!

In closing, we have a lot of great things going on as a community just 16 short months since we launched the project, and we’re just scratching the surface of the opportunity ahead. Our future is bright, let’s really put on the gas as we head into the tail end of 2018!

Regards,

Jason Shepherd

Chair of the Board, EdgeX Foundry

EdgeX Foundry Member Spotlight: Linaro

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with François-Frédéric Ozog, Director of the Linaro Edge & Fog Group, to discuss open source, the edge, the impact EdgeX has made in their business and what the future holds for the company.

What does Linaro do and what is your role within the company?

Linaro gathers Arm ecosystem partners and leads collaborative engineering efforts. It helps companies work with the latest open source technology, build support in upstream projects, ensure smooth product roll outs and reduce maintenance costs. It is a major contributor to more than 70 open source projects and is consistently listed as one of the top five contributors to the Linux Kernel. I lead the group that focuses on the Edge & Fog upstream projects such as EdgeX Foundry and the Akraino Project.


Instead of duplicating efforts, Linaro members share development costs of core platform technologies to accelerate innovation and time to market. Linaro segment groups (Data Center & Cloud, IoT and embedded, Edge & Fog, Consumer) tackle market specific requirements. The IoT and Embedded group is focused on the things themselves with Zephyr Real Time OS while the Edge & Fog group is dedicated to solving gateways and edge computing nodes.

Why is your company investing in the IoT ecosystem?

The success of IoT relies on economically efficient solutions. This assumes software shall transparently leverage any available hardware features across processor architectures and models. Linaro and its members are collaborating to maintain Arm leadership and promoting cross architecture support.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them?

There will be multiple edge stack solutions at least for regulatory reasons: a manufacturing edge gateway does not have the same regulatory constraints as an automotive edge node. Furthermore, a single node may host a number of stacks with different orchestration environments. From a feature perspective it makes no sense to unify all stacks and orchestration solutions. As a result, Linaro is building a common platform software substrate that can be used by all stacks and all orchestration solutions to simplify overall ecosystem control.

Why did your company join EdgeX Foundry?

Linaro sees EdgeX Foundry as an important edge stack that can be applied in a wide range of use cases. As a result, Linaro members want to ensure the stack can benefit from efficiency advances of any Arm processor providers to ensure best TCO.

If you’re interested in Linaro, Linaro Connect will take place on September 17-21 in Vancouver. Below are the edge-related tracks and the link to register: https://connect.linaro.org/register/.

Edge computing:

The Networking of Edge Computing and Edge Stack on Arm Platform  

The practice of Contiv/VPP high performance container networking solution on Arm platform

Network switches and TSN configuration

LEDGE/Automotive reference platform

System Firmware and Device Firmware Updates using Unified Extensible Firmware Interface (UEFI) Capsules

Edge AI with Linaro

A Call to Action: Accelerating Python with FPGAs

Security:

BoF: IOT Security with Arm OSS

Isolation using virtualization in the secure world

EB corbos and the L4Re microhypervisor: Open-Source Automotive Safety

Xen on ARM for embedded and IoT: from secure containers to dom0less systems

Containers in Embedded

Securing the Edge with EdgeX Foundry’s California Code

The recent EdgeX Foundry release, “California”, was the first to introduce security features built right into the platform. Operating on the edge means deploying hardware and running software outside the confines of well managed data centers, making IoT devices more vulnerable to exploitation by hackers. Our new security features make it easier to keep your data safe even when deploying solutions in insecure or untrusted environments.

The two new security services introduced in this release are the Security Secret Store, and the Security API Gateway. Between them they allow you to safely store sensitive information, such as encryption keys or authentication credentials, and restrict access to the data being processed by EdgeX to only authorized users and applications.

Security Secret Store

The Security Secret Store allows microservices to safely store and retrieve sensitive data that is only accessible after the secret store has been unlocked by an authorized service. Your secrets are encrypted both on disk (Consul backend) and during transport (TLS 1.2) to and from the Security Secret Store, ensuring that only the microservices that are authorized to access it can do so.

EdgeX Foundry uses Vault, by Hashicorp, as the reference implementation of the Security Secret Store. Vault provides a well tested secret storage solution with a failover architecture and flexible levels of control over access.

Security API Gateway

EdgeX Foundry is composed of a number of microservices that communicate with one another using standard networking protocols. This allows for a great amount of flexibility in how you deploy parts of the stack in your solution, but it also directly exposes the microservices to anybody who can connect to them. The new Security API Gateway provides a way for you to restrict outside access to your data by acting as a middleware between external applications and the EdgeX platform, requiring authentication before forwarding commands or read requests on to the relevant microservices.

EdgeX Foundry uses Kong as the reference implementation for the Security API Gateway.

For more information:

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

Part 2: The Evolution of EdgeX’s User Interface

Written by Vinoyang, EdgeX Foundry Technical Contributor and Tencent Big Data Engineer

This is the second part of the EdgeX User Interface blog. The first part of the blog focused on the work that was recently completed. You can read part 1 here. This blog will detail where we are now and where we’re headed with the next code release, named Delhi, later this year.

This blog will be divided into several sections:

1. Prepare for the participation of the community;

As mentioned earlier, the structure of the project is standardized, the details of the README file are enriched, the Make file is provided to improve the ease of use of the project, and the ongoing integration is to verify the validity of the community PR, etc..  All of this work helps insure we are ready to accept contributions from the EdgeX community.

Regarding continuous integration, I have been communicating with Jeremy Phelps of EdgeX Foundry’s DevOps working group. As with all of EdgeX, we hope to use Jenkins as the continuous integration tool for the new UI as well. In addition, we will integrate code quality inspection tools to protect the edgex-ui-go code quality.

2. Persist the data to the database and lay the foundation for subsequent database switching

As mentioned above, the data storage method implemented by edgex-ui-go is simple and a bit crude. It caches data in memory. As we all know, memory is volatile, and once power is lost, all data will be lost. Therefore, we must provide data persistence capabilities for the edgex-ui-go. We hope that the logic of edgex-ui-go maintains a loosely coupled relationship with its database, which will allow edgex-ui-go to switch between different databases according to user needs. So we implemented a data access interface (DAO for existing domain objects), and those who have worked on Java Web development should be familiar with this design pattern. Currently, I am developing a DAO implementation that interfaces with the  MongoDB database.

3. Using a classic three-tier architecture for the web backend

“Control/service/dao” is a classic three-tier architecture for Web backends. Its advantage is to implement a layered structure. We are also refactoring the code to use this design pattern.

4.  Reliable login verification

As we all know, security is a big problem that the Internet of Things faces. EdgeX Foundry also believes security is important. The TSC F2F conference in early June focused on security issues. The Edgex UI landing page may be one of the first and most critical interfaces for users to interact with EdgeX. So, we have to make sure that edgex-ui-go has a logical login authentication function.  I will be working with David Ferriera, chair of the Edgex Security Working Group to select and use one of multiple alternatives to provide user authentication.

5. Integration testing with the GoLang version of the microservices released by EdgeX California

The California version of EdgeX has been released.  The entire EdgeX Foundry community is excited, because this is the first version of EdgeX based on GoLang implementation (I was fortunate to have been a big participant in the development of the first version of EdgeX in GoLang). edgeX-ui-go is currently integrated to the old Java version of the EdgeX microservice. In this next refactoring effort , we are integrating and testing edgex-ui-go with the GoLang microservices. This will help improve consistency, integrity, stability and availability of the entire EdgeX ecosystem in GoLang.

6. Build a Docker image of edgex-ui-go

As with all EdgeX microservices, we need to containerize the edgex-ui-go for easy of deployment.  However, this is a lesser priority in our current work.

7. Fix some remaining bugs

At present, most of the base UI is working, but there are a few bugs to fix.  For example, the device profile cannot be upload as required, but we are working to solve these issues.

The EdgeX UI as part of the Delhi Release and Future Work

So what’s the plan for formally releasing the new UI?  The current work – and all the refactoring, is expected to be released with the Delhi Release of EdgeX (October 2018).

Beyond the current release there is more work to complete.  First, we want to push the front end of edgex-ui-go. At present, the front end of edgex-ui-go can be said to be very rudimentary, and data visualization capabilities are very limited. Currently I am researching and experimenting with an open source and powerful admin template named gentelella. Here is an example of the type of data visualization that gentelella can produce.

The reasons for using this type of UI tool are as follows:

  •      A feature-rich, elegant interface UI that will give user a good first impression of edgex
  •      Easy to use; which is important in a community were very few community members have professional front-end development experience, and most people only have experience in developing back-end languages
  •      A popular template capability that can save a lot of front-end workload, such as interface layout, settings, components (such as login, table, forms, uploads, downloads, etc.), and is created by many people with professional experience

We also hope to add support for more management and visualization of EdgeX itself. At present, edgex-ui-go provides only simple support of device onboarding, export client registration, rule configuration and other functions.  We hope to provide more and improved management capabilities to include better metadata management, scheduler management, log viewing, and more. At the same time, we expect to collect more EdgeX user needs for monitoring and visualization and incorporate those needs into future implementations.

Edgex-ui-go is part of the community effort. If you want to participate in EdgeX UI development, we welcome your comments, suggestions, bug fixes, code contributions and reviews. Find out more on our wiki page here

Or, you can visit EdgeX Rocket.Chat and share your thoughts in the #community channel.

Part 1: The Evolution of EdgeX’s User Interface

Written by Vinoyang, EdgeX Technical Contributor and Tencent Big Data Engineer

This is a two-part blog that introduces a User Interface project in the incubation area of the EdgeX Foundry. This first blog post will disclose some of the work that was recently completed. The second blog will detail the latest developments and plans for this UI project in the future.

edgex-ui-go Refactoring

First, I’d like to thank Huaqiao Zhang from VMware for providing a Java version of the implementation of EdgeX UI. This was a huge milestone as it provided EdgeX with its first user interface:

Based on discussions with him, we decided to follow the EdgeX Foundry direction and use GoLang for the backend EdgeX UI’s operations. This  allows it to more easily operate in more resource constrained IoT edge environments. In fact, Huaqiao recently completed work on an initial GoLang implementation. A screenshot from Github of the initial Go implementation is below.

This version basically matches the capabilities provided by the original Java version. After he provided the initial version, I made a holistic and comprehensive review of the entire project. There were some areas for improvement with the initial version and work that needed be done before the work is ready to be accepted by the community. Here is a list of the improvements that needed to be made:

  • The overall layout and directory structure of this project is not a general practice of GoLang
  • There are common project code normative issues: such as hard-coded, annotated code, inconsistent code format, etc.
  • The project’s README file does not have a detailed description of the project, such as installation, deployment, compilation, and operation instructions
  • Mixed use of console printing and logging
  • Relevant information is stored in memory (volatile storage) and does not provide a database-based implementation
  • Missing a real login verification implementation
  • Lack of continuous integration to support validation of PR validity

Much of the work came from the fact that we first concentrated on simply converting the Java version to GoLang version.  As with much of the EdgeX development team, Huaqiao has just begun to learn the Go language and there was also work to do in order to bring the code into alignment with standard Go idioms, design and practices.

Overall, we corrected more than 25 issues (there are still more than 15 issues that are not outstanding). Now the code base looks like this:

Importantly, we also worked to simplify the getting, building and running of the new UI.  Now even a new EdgeX UI user, one who is completely unfamiliar with GoLang, can run a local version of EdgeX-UI by using a series of make commands.

This simplicity was not there in the initial version.

This blog focused on providing a version of the Golang implementation for edgex-ui and refactoring it so that it matches the functionality of the original Java version but looks more like a Golang project. We’ve made significant progress but the work isn’t over yet. In part 2 of this article, which will post next week, I’ll  introduce where we are now and where we’re headed with the next code release named Delhi later this year.

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

Welcome California!

Written by Jim White, Vice Chair of the Technical Steering Committee and Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division

The second major release of EdgeX Foundry is now available!

While EdgeX is only a year old, our community is demonstrating its staying power with the second major release in its first year.  The California release, which follows Barcelona, shows the commitment and dedication of many who see the importance and potential of developing a flexible, open source, IoT software platform for the edge that provides connectivity and interoperability while still allowing value add.

So, what is new with the California release?  A lot! But before we get into the details, I want to highlight that the biggest focus of this release was to introduce a few key security capabilities and to make EdgeX smaller and faster.

Security

EdgeX began its existence without security and organizations wanting to leverage the platform had to add their own security capability. Today, EdgeX incorporates some of the first security elements.  These initial elements, while useful on their own, are essential building blocks to additional security features in the future.

The first security elements include a reverse proxy that helps protect the REST API communications and a secrets store.  With the EdgeX reverse proxy in place – as provided by incorporating an open source product called Kong – any external client of an EdgeX micro service must first authenticate themselves before successfully calling on an EdgeX API.

The secure storage facility was provided by incorporating the open source Vault (Hashicorp) product, and it allows items such as username/password credentials, certificates, secure tokens, etc. to be persisted and protected within EdgeX.  These types of “secrets” will allow EdgeX to, for example, encrypt data, make HTTPS calls to the enterprise, or connect EdgeX to a cloud provider in a secure manner.

Performance and Scalability

The EdgeX Foundry Technical Steering Committee decided early last year in the project’s formation that we would release twice a year – once in April and once in October.  You probably noticed that it’s not April.

Last year, we decided that EdgeX needed to be smaller and faster to better function effectively at “the edge”, which the largely-Java code from the seed donation was going to make difficult. To do this, we needed to rebuild the EdgeX microservices in Go Lang – and do so by our spring 2018 release.  This was not a small endeavor and it was made at a time when the EdgeX Foundry developer community was just coming on board.  We knew it would take a bit more time, but we were committed to this, and added two more months to this release cycle.

The extra time was well worth it!  With the California release, we’ve dramatically lowered the footprint, startup time, memory and CPU usage. Take a look at the statistics below, which compares services from our first community release last October (Barcelona) to our current release (California).

We still have work to do, but it’s now possible to run all of EdgeX on something like a Raspberry Pi 3.

Additional Features

In addition to the initial security capabilities and reducing the size and latency of the platform, this release includes other work – some visible to the user while some features are more hidden but improve the overall quality of EdgeX.

  • Several additions were made to the export services to provide additional “northbound” connectivity, to include connectors for XMPP, ThingsBoard IoT, and Brightics IoT
  • We improved the documentation and now have documentation stored with the code in Github – allowing it to be maintained and updated more like code by the community
  • Arm 64 is now fully supported.  In fact we worked with the Linux Foundation to add external environments and tools to create native Arm 64 artifacts.
  • We added blackbox tests for all the micro services.  These are now kicked off as part of our build and continuous integration processes.
  • Other improvements were made to our continuous integration – to help streamline developer contributions

We invite you to try out the California release today (Docker Compose file here)!  

On to Delhi

Our next release, named Delhi, will come out in October 2018.  Due to the extended release cycle for California, the Delhi release cycle is going to be short. The significant features planned for Delhi include:

  • Initial manageability services and capability
  • Device Service SDKs (Go/C) and at least one example device service
  • The next wave of security features to include access control lists to grant access to appropriate services and improved security service bootstrapping
  • Better/more unit testing and added performance testing
  • Adding the last of the refactored and improved Go Lang microservices
  • Outlining options and a potential implementation plan for alternate or additional database support
  • An EdgeX UI suitable for demos and smaller installations

Come join us!

We would like to thank the talented men and women who are working very hard to turn the vision announced when the EdgeX project launched in April 2017 into the product we see emerge and improve with each release.  In the past six months, we have seen the number of unique authors contributing to the project code base double to more than 50. We hope you’ll consider joining our growing development community to build on this momentum by contributing to the Delhi release as well as using EdgeX in your edge/IoT solutions!

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

Spreading EdgeX Foundry News in Asia

Written by Jim White, Vice Chair of the Technical Steering Committee and Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division

Over the past couple of weeks, I have been traveling to China and Japan to attend the LinuxCon/Container Con/CloudOpen (LC3) conference in China as well as IoT meetups for EdgeX Foundry in Beijing and Tokyo.

As the name of the LC3 implies, it was actually 3 conferences in one and thus a full venue of keynotes, sessions and events spread over 3 days.  I was impressed by the overall scope and attendance of the conference. While there was a predominance of Chinese companies and speakers as one would expect, this was a global event with attendees and speakers flying into Beijing from all over the world.

Speaking at the LC3 show were the likes of Linus Torvalds, Chris Aniszczyk (Cloud Native Computing Foundation – CNCF COO), Abby Kearns (Cloud Foundry Foundation Executive Director), Dan Kohn (CNCF Executive Director), and Alan Clark (director for openMainframe and member of the CTO office at SUSE).  I presented a talk to around 50 attendees about using a microservice architecture to address the needs of edge computing – using EdgeX Foundry as an example. You can view the presentation here.

In addition to my talk on microservices and EdgeX, there were 11 talks over the three days in the IoT & M2M track.  A few of the ones I found interesting were:

Tiejun and his team are doing great work on all sorts of IoT-related matters.  I had a chance to visit with them at the VMware Beijing office and got to see one of his experimental robots using EdgeX!

Tiejun also played an integral role in orchestrating an EdgeX Foundry Meetup to occur simultaneously with LC3 – giving even more awareness to EdgeX in China.  Around 40-45 people showed up at the Meetup to hear a great roster of speakers share their experiences with our open source project and EdgeX Foundry member The Zephyr Project. In fact, Professor Yonghua Li from Beijing University of Posts and Telecommunications (BUPT), which is a member of both EdgeX and Zephyr, brought a few of his students along so they could discuss how they are using the EdgeX framework and the Zephyr RTOS in their IoT solutions. You can read more about their work in this blog post.

Another one of the speakers was Huaqiao Zhang from VMware (pictured below) speaking about the EdgeX UI he recently contributed to the project. This will be released with the Delhi release in October. Check out the roadmap.

For those not keeping up on all the EdgeX Foundry news, the Industrial Internet Consortium, (IIC) recently announced the formation of the first Optimizing Manufacturing Processes by AI (OMPAI) testbed and it will be led by Wanxiang Group out of China. Read the blog post here.

China is a global leader in machine-to-machine (M2M) technology, which allows devices to wirelessly exchange information and execute tasks. M2M connections can communicate in various ways, including Wi-Fi, Bluetooth, and cellular. Interoperability is an important piece to this puzzle and I think that’s why there was so much interest in EdgeX Foundry in China. We hope to continue working with our members in China like VMware and the Wanxiang Group to coordinate more meetups and continue spreading awareness for EdgeX Foundry through WeChat. If you would like to be added to the EdgeX Foundry WeChat group, please email info@edgexfoundry.org with your WeChat ID.

Next on the Agenda: Tokyo

While in Japan visiting with a number of Dell Technologies customers, I had the pleasure of presenting at a Tokyo EdgeX Foundry Meetup.  Around 50 people were at this event – making it the most well attended EdgeX Meetup at which I have had the pleasure to present. Even more impressive was the fact that more than half my audience had been up since 3 am that morning to watch the Japanese national team in elimination round of the 2018 World Cup!  Interest in IoT is palatable in Japan – especially for use in the manufacturing sector.

 

The desire to learn more about edge computing and EdgeX Foundry was considerable from the Tokyo IoT crowd with the Q&A portion of my talk lasting almost as long as the talk itself.  The Q&A discussion even spilled over into a great drink/appetizer social afterwards. It was truly an engaging group and a fun afternoon.

Questions from this community included:

-Why did EdgeX chose Go? Because of its multi-platform support, ability to compile to a native executable and run small/fast and its concurrency model among other reasons

– Is EdgeX Foundry involved in standards work? EdgeX Foundry community members are actively involved with Industrial Internet Consortium (IIC), OpenFog Consortium, IEEE and many other industry and consortia groups and will work to be an implementation of edge standards we think are beneficial to the space, but we are not trying to get EdgeX to be a standard.

– Are EdgeX and Edgecross related projects? The Edgecross Consortium is a Japanese-based organization that is currently working on a Windows-based edge platform that members of our community continue to have discussions with, but there is no relation between the two projects today.

Next year, The Linux Foundation announced LC3 will simply be called Open Source Summit China, which will be held in Shanghai. If you’re interested in IoT, open source and more, put the Open Source Summit China or Open Source Summit Japan on your conference list.  I don’t think you’ll be disappointed in what you’ll see and learn there.

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

Michael Hall Joins EdgeX Foundry

Written by Michael Hall, Project Evangelist and Developer Advocate for EdgeX Foundry

This week, I began a new chapter in my career by joining The Linux Foundation as a developer advocate and community manager for the EdgeX Foundry, an open platform for IoT edge computing.

I started using open source before I even knew what it was. Perl was my first programming language, and so installing libraries from CPAN became a routine task (as well as a routine challenge on SunOS). I posted my first open source code on SourceForge soon after, still thinking of it as a way for hobbyists to share their hobby, but not as something serious developers or companies would do. I still remember the feeling I had when Netscape announced that the next version of their browser, Netscape Navigator 5, would be released as open source. As a web developer in the late 90’s, Netscape was the killer app, the king of the hill, the virtual monopoly that was leaps and bounds ahead of IE4. For them to release their source code in a way that let other people see it, copy it, even improve on it, was revolutionary. And it changed forever the way I thought about open source.

Of course, anyone who lived through those turbulent times knows how that Netscape 5 story actually turned out, not because it was open source but because of business decisions and buyouts (thanks AOL!) that kept pulling the development one way and then the other. But my own journey into open source was much more straight forward. I dove in completely, releasing everything I could under an open license, using as much openly licensed software as possible. I bought (yes bought) my first copy of Linux from Best Buy in 1999, and switched my desktop permanently in 2006 when Canonical mailed me a free CD of Dapper Drake. Five years later I would join Canonical myself, and eventually land on the Community Team where I was building new communities and growing existing ones around Ubuntu and all its upstreams and downstreams. Last year, I was doing the same at Endless Computers, bringing the benefits of open technology to users in some of the most remote and disconnected parts of the world.

So, having the opportunity to join the Linux Foundation is a dream come true for me. I’ve seen first-hand how collaboration on common technology leads to more and better innovation across the board, and that is the core idea behind the Linux Foundation.

I’m excited to be joining EdgeX Foundry, which will play a crucial role in developing the way the rapidly expanding number of IoT devices are going to connect and communicate with the already massive cloud ecosystem. I will be working to improve the way new developers get started using and contributing to EdgeX Foundry, as well as teaching new organizations about the benefits of working together to solve this difficult but shared problem. I look forward to bringing my past experiences in desktop, mobile and cloud developer communities into the IoT space, and working with developers across the world to build a vibrant and welcoming community at the network edge.

Follow me at @mhall119  and stayed tuned at @EdgeXFoundry for more. Or, if you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

University Students Leverage EdgeX Foundry and Zephyr OS in New Projects

Written by Professor Yonghua Li with Beijing University of Posts and Telecommunications (BUPT) and active EdgeX Foundry and Zephyr Project member

The Beijing University of Posts and Telecommunications (BUPT) recently became new members of EdgeX Foundry and the Zephyr Project but students studied both projects long before then. In fact, students are currently working on IoT projects that are based on these open source technologies.

The first project uses the EdgeX platform (using the Java micro services) running on a Raspberry Pi. EdgeX Foundry core, supporting and export micro service artifacts were created in Eclipse using Java Maven.  Docker containers were created around the micro service artifacts and deployed to the Pi running Ubuntu 16.04 Linux using Docker Compose. In addition to the EdgeX export, core, and supporting micro services, the students choose to build and deploy an MQTT based device service to ingest sensor data into EdgeX which utilized CloudMQTT as the underlying broker.

For this project, the students used a random number generator to simulate sensor data on the Pi.  The simulated sensor data was passed in with an MQTT messages through the device service (again utilizing CloudMQTT) while receipt messages were sent back out from the device service through another MQTT pipe.  Because of CloudMQTT’s WebSocket user interface, students could easily view the JSON-wrapped random number data enter EdgeX as well as be acknowledged by EdgeX – demonstrating the successful establishment of an IoT edge platform.

EdgeX Foundry uses the random number as messages through the MQTT Microservice, passes it to CloudMQTT, and receives the response again through the MQTT Microservice. CloudMQTT’s WebSocket UI allows you to view JSON random number data and send data to EdgeX, demonstrating the successful establishment of it.

The other project aims to develop a Bluetooth-enabled heart rate monitor based on Zephyr OS, which is ideal for resource-constrained systems and small IoT devices. The system implements heart rate measurement for users and transmits the user’s heart rate data to user’s mobile phone via Bluetooth, so that users can monitor his or her heart rate in real-time.

The system is mainly divided into two parts: hardware and software. The main functions of the hardware is data collection, data transmission and data display. The hardware is designed and implemented centered on the Arduino101 development board. On the other hand, the software is mainly used for data conversion and analysis. The development and implementation of software are performed under Zephyr OS.

If you’d like to learn more about the BUPT student projects, we invite you to join the IoT Meetup on Tuesday, June 26 from 6-9 pm at VMware’s office in China. There is no cost for this event but space is limited, so RSVP is required. Register now https://www.bagevent.com/event/1491965   

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

IIC announces 1st OMPAI testbed based on EdgeX Foundry

Written by Jijun Ma, Member of the EdgeX Foundry Governing Board and Industrial Internet Director at Wanxiang Group

The Industrial Internet Consortium® (IIC) announced the Optimizing Manufacturing Processes by Artificial Intelligence (OMPAI) testbed yesterday. The OMPAI testbed is led by IIC members Wanxiang Group (also a member of EdgeX Foundry) and Thingswise and supported by Dell EMC (a founding member of EdgeX Foundry), Xilinx, China Unicom, and China Academy of Information and Communication Technology (CAICT).

The OMPAI testbed, which is the first testbed based on EdgeX edge computing platform, explores the application of artificial intelligence (AI) and industrial internet technologies, deployed from the edge to the cloud, to optimize automotive manufacturing processes. It also seeks to create an ecosystem that will foster the exchange of IT/AI/OT domain knowledge and the co-development of smart manufacturing applications. For example, deep learning may be able to improve quality assurance of an automobile part to substantially increase the detection of defects and reduce the need for manual inspection.

Vincent Wang, Chief Innovation Officer of Wanxiang Holdings, said, “As a leading multinational corporation in automotive and renewable energy, with factories in Europe, North America and Asia, we believe that an industrial IoT platform will be a key enabler for our digital transformation and global synergy. We are glad to work with technology leaders to validate AI, edge-cloud collaborative computers, and high-speed cellular networks to optimize manufacturing productivity and quality. This is the first step toward an open, inclusive IIoT platform on which we will continue with further testbeds, incorporating new ideas, new data usage models and creating greater value add. We invite worldwide enterprises, innovators and entrepreneurs to enrich the ecosystem together.”

In the edge platform, AI models and edge applications are run for the local optimization of manufacturing processes. In the cloud platform, they are run to enable global and long-term optimization, e.g. across production lines and plants. The edge platform also supports connectivity to and data collection from the equipment while the cloud enables historical data accumulation and storage and supports AI model building.

The cloud computing platform also provides the capability for enabling industrial app DevOps processes supporting collaboration between AI/IT developers and plant engineers in creating, testing and running data/AI model-driven industrial applications. The following image shows the solution overview of this testbed.

Blow are the usage scenarios in our testbed.

Machine vision on-line quality assurance

The main theme of this scenario is to exploit the capability of deep learning in image pattern recognition to improve quality assurance effectiveness and efficiency by increasing defect detection accuracy, reducing dependence on manual inspection and at the end providing online feedback to the production process to reduce defect rate.

Battery Cell Welding Quality Control

In this scenario, it is going to use historical data to analyze the relationship between the welding process and environmental parameters and the product quality and use that to predict in real time quality product and provide recommendation for optimization.

Wheel Bearing Production Line Balance & Optimization

A high throughput discrete manufacturing line usually consists of many workstations involving with various equipment and processes. These workstations may have different production throughput that vary depending on their process parameters. Mismatched throughput between the workstations would impede the overall production line throughput, reducing overall equipment utilization and production capacity.

Big data analytics on data collected from the workstation equipment can be used to monitor production pace of each of the workstations and overall throughput, and to identify bottlenecks and recommend optimization solutions.

Predictive Maintenance of grinding machines

In a manufacturing environment, equipment failures interrupt production lines or cause product quality issues, aggravated by the prevailing condition that few or no spare parts are usually kept for key equipment, e.g., grinding machines and motors, resulting severe reduction of production capacity in the event of equipment failures.

The current solution of “preventive maintenance” relying on periodic manual inspection is ineffective, laborious and interruptive to production. Predictive Maintenance for the equipment enabled by machine learning will be experimented within the general framework to effectively address this common manufacturing issue.

This testbed is open to new innovative ideas and EdgeX Foundry members are welcomed to join us to widely use EdgeX for industrial internet solution.

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

Another Great F2F TSC Meeting

Written by Keith Steele, CEO of IOTech and EdgeX Foundry Board Member and the Chair of the Technical Steering Committee

Last week, we held a Face-to-Face Technical Steering Committee meeting in Palo Alto. It was another successful one and, after each meeting, my confidence grows that the EdgeX Foundry project will achieve great things.

Before reflecting on the week, I’d like to pass on my thanks on behalf of the community to VMware who hosted the event at their wonderful Palo Alto facility. California Burritos from their cool on-site restaurant was a culinary discovery for me!

EdgeX Foundry passed our one-year birthday in April, so from the EdgeX Charter standpoint, we now move from ‘start up’ phase to ‘steady state.’

While the term ‘steady state’ in the Project Charter refers to a transition to TSC members being voted from the contributing community, it’s a bit of a misnomer when you look at the project activity. This F2F TSC meeting demonstrated that EdgeX is far from static as it grew in attendance when compared to the last F2F meeting. More than 40 people showed up in person from all 4 corners of the world and many more joined by phone. We’re still very much in growth phase…

Elections were held for the TSC and we welcome new Working Group chairs Steve Osselton (Device Services, from IOTech), Trevor Conn (Core, from Dell) and David Ferriera (Security, from ForgeRock). Likewise, we thank Salim AbiEzzi, Doug Gardner and Tony Espy for their contributions on the TSC over the past year, all three will remain active participants in the project going forward.

So, on to the meeting…

The main discussion for the meeting was the status of the California Release, which is projected for early July and the roadmap for the Delhi release due in October.

Here’s a short list of what was scoped for the Delhi release:

  • Device Service SDKs in Go and C will be previewed this summer and formally released with Delhi (including some representative device services).
  • Performance targets for EdgeX are already being hit, but performance testing as part of the continuous integration and release process will be incorporated.
  • Support for binary data to be processed by EdgeX for the first time to allow for carrying video images, audio data, and the like.
  • The initial system management functionality will include an API for the management of the micro services and an agent to coordinate with other application/cloud infrastructure.
  • Refactored services to incorporate better isolation to allow for future replacement of infrastructure elements such as the local persistent store or message infrastructure.
  • The addition of an EdgeX UI which will be previewed this summer but officially released with Delhi.
  • Research and design on a new Application Services layer to replace the existing Export Services layer of EdgeX will be published with plans to have implemented with the Edinburgh release (scheduled for April 2019).

Research and recommendations on options for the placement of MongoDB as the included reference database will also be announced with Delhi with the intention of offering changes by Edinburgh release.

I was really impressed with the level of collaboration and cooperation at the meeting as there was fabulous participation from all. If you couldn’t make it, this is a timely reminder that EdgeX Foundry is an open project and the recordings of the meeting can be found here.

One thing we did at this meeting, which I thought worked well, was we held a separate Face-to-Face meeting for the Device Working Group prior to the main meeting. Doing this enabled much deeper technical collaboration on important issues before the main meeting. I think this is something we should formalize into our meeting structure across all groups in future meetings.

Additionally, Samsung sought support for updating the project positioning and received it from the TSC. The suggestion is to avoid branding that suggests EdgeX as a strictly industrial IoT platform, especially since EdgeX can be used in much broader IoT solutions to include enterprise, consumer and mobile edge environments. While we will continue to strive to make the platform suitable for industrial workloads, the project will begin to ensure EdgeX Foundry marketing and literature addresses its broader capabilities.

This will certainly lead to a growth in the scope of the Vertical Working Group activity but market positioning was referred to the EdgeX Marketing group with TSC input provided.

The next F2F TSC meeting will be held in my home town of Edinburgh on October 23-24. You can register here and find more information available on the EdgeX Wiki.

We look forward to collaborating with you there!!

Best Regards,

Keith Steele, TSC Chair

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

EdgeX is now fully ARMed

Written by Gorka Garcia, Active Contributor in the EdgeX Community and Senior Lead Engineer at Cavium Inc.

Cavium joined EdgeX Foundry last year and has been committed to get full support for ARM64 in EdgeX, as we explained in our previous blog post. One common drawback of many open source projects is the lack of both build and test in ARM platforms in their Continuous Integration systems (CI systems). This issue can affect customers – it takes time and effort from their engineering resources to work with open source projects and integrate their platform of choice. This directly affects time to market.

On March 1, the Cavium team reached a very important milestone in the process of having ARM64 support in EdgeX Foundry. We got our first EdgeX ARM64 native build and test in the CI system! Since March 1, this machine has performed more than 700 builds with their corresponding unit tests.

The Linux Foundation, which is responsible for the CI system, helped by running it on an OcteonTX platform in Cavium premises and integrating this OcteonTX platform as a build executor node in Jenkins, the CI system. With their help and comparing what was done for PC, we managed to install all the dependencies and had it working in a short time. Since March 1, this machine has performed 26 build works and there have been 141 snapshots of the ARM images built total.

Moving forward, the EdgeX community will be notified of any changes on the source code that affects ARM64 compilation and testing. The next step in this process will be getting CI system to also perform black box testing in the same platform.

Additionally, Cavium recently announced support for EdgeX on its OCTEON TX® family of products, including the CN80xx/81xx and the CN83xx series. Click here for more details.

For more information:

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.