Skip to main content
Category

Blog

Welcome new LF Edge Governing Board Members!

By Blog

As we enter the second half of 2022, we’d like to take a moment to recognize some recent changes to the structure of the LF Edge Governing Board as terms end and new ones begin. 

Specifically, we’d like to extend a big THANK YOU to Jason Shepherd of ZEDEDA for his years of service as Chair of the LF Edge Governing Board. During his tenure, LF Edge grew exponentially, adding new projects and new members as well as a library of original resources including white papers, user stories, and more. Additionally, Ryan Anderson of IBM has ended his tenure as the Board’s representative from IBM after years of service. Thank you, Jason and Ryan!  

We’d like to welcome our new Board Chair, Tina Tsou,  Enterprise Architect, Arm and IBM’s new representative, Hakan Sonmez, Product Strategy & Operations Manager, IBM Edge Computing & Software Defined Networking business unit. 

Learn more about Tina and Hakan below.  

Tina Tsou, Board Chair

Tina Tsou is an innovator and a visionary with far-reaching accomplishments within the technical engineering realm. As Arm’s Enterprise Architect, Tina serves in the highly visible Technical Lead role for the Enterprise Open Source Enablement team, where she analyzes, designs, and implements robust strategies to establish first tier status for Arm’s architecture within open source communities and projects. Tina also serves as Arm’s Edge Computing Team Lead. As the company’s open source thought leader, she builds powerful partnerships with and influences open source communities in support of multiple architectures.

Tina previously served as the Digital Domain Expert (Connectivity) for Philips Lighting, where she implemented NB-IoT in an outdoor carrier project with China Mobile and Huawei. She released Bluetooth + ZigBee combo chip architecture and delivered a connectivity hardware/software platform (ZigBee 3.0, Wi-Fi). The United States Patent and Trademark Office has granted Tina 100+ patents. 

She earned her Bachelor of Computer Science degree from Xi’an University of Architecture and Technologies. Tina was the first woman to chair an Internet Engineering Task Force (IETF) working group from a Chinese business enterprise and was the youngest Asian rapporteur in ITU Telecommunication Standardization Sector (ITU-T) history. She previously served as Chair of the Akraino Technical Steering Committee. 

Hakan Sonmez, Board Member

Hakan currently serves as a Product Strategy and Operations Manager at IBM’s Edge Computing and SDN business unit. His focus areas are Edge computing, Hybrid Multi-Cloud Networking and applying AI/ML to multi-cloud operations. He works closely with IBM technical leadership on the Open Horizon project of LF Edge. Previously, he was a lead consultant at IBM Corporate Strategy team.

Prior to IBM, Hakan held various technology roles within the Networking and Telco industry, including Cisco Systems, Airvana Networks, Sycamore Networks and NextWave Wireless.

Hakan holds a BS in Electrical Engineering from Middle East Technical University, an MS in Electrical Engineering from Northwestern University, and an MBA degree from MIT Sloan School of Management.

As a reminder, the Governing Board is made up of members across the project, including one rep from each Premier member; elected General member representatives; and one rep from the Technical Advisory Council. Primary responsibilities include overall management of LF Edge, including budget creation and approvals, oversight of community outreach matters, approval of technical projects, establishment of end-user advisory councils, and more

For a list of current LF Edge Board members, please visit: https://www.lfedge.org/governance/governing-board/

Preventive Healthcare using Intelligent Edge IoT Computing – ‘Round the Clock EHR’

By Blog, EdgeX Foundry

By:  Utpal Mangla – Industry EDGE Cloud – IBM Cloud Platform;  Atul Gupta – Lead Data Architect – IBMLuca Marchi – Industry EDGE and Distribute Cloud – IBM Cloud Platform; and Saurabh Agrawal – Practice Lead, Network Cloud, 5G & EDGE 

Preventive healthcare has always been taught and talked about in most healthcare institutions, but seldom practiced. The collective benefits are immense, and the realization of a fraction of those benefits can help optimize the cost-delivery aspects of healthcare services. It can also act as a catalyst for scaling healthcare services for growing populations in most parts of the world. 

The common issues in implementing Preventive Healthcare include providing guidance, educating the vulnerable population masses, and interacting with healthcare professionals. Most of the challenges in regular screenings or monitoring of diabetes, cholesterol, cancer, and mental health are known cost and labor related issues.

Technology has helped to achieve some primary objectives, but the ultimate goal is still far away. IoT and Robotics solutions have been deployed in healthcare facilities and continue to advance quickly.  But with new tools, techniques, and cloud infrastructure,  it’s time for innovative new solutions that come with  emerging IoT devices, like increased connectivity, speed, and lower costs. 

 

Intelligent Edge IoT can provide intense data gathering and processing before sending the prepared data into the Health Ecosystem. Early on, IoT’s were mostly sensors used to gather data and were often cumbersome when it came to software code updates, and they didn’t have enough compute power to run any data processing. The new generation of intelligent IoT’s, which can be deployed at the Edge, can compute and process data ahead of sending it to Cloud computing functions for more sophisticated analysis, including machine learning and deep learning algorithms.

These intelligent IoT’s once deployed as human wearables, facility sensors, etc. can transform EHR (Electronic Health Record) to next generation 24x7x365 EHR (Round the Clock EHR)

This innovation of ‘Round the Clock EHR’ can transform the healthcare industry by bringing healthcare professionals much closer to patients in understanding and diagnosing medical issues early on. It can continuously stream and feed data to ML (machine learning), DL (deep learning) algorithms to help and improve AI solutions. The risk factors can be constantly monitored, thresholds can be adjusted and re-calibrated in real-time with sophisticated software. The Preventive healthcare can not only detect the early signs but also feed it to research facilities for new research programs and eliminate unnecessary analysis. 

The Preventive care strategies which also encompass social and environmental conditions can now be monitored with the ‘Round the Clock EHR’, which contains the patient or potential-patient data along with their detailed data on living conditions, geographical conditions, social setup which may trigger onset of a disease or unfavorable conditions. On a larger scale, the Healthcare ecosystem data and ‘Round the Clock EHR’ can provide feed into wider studies to generate health patterns as people move and Preventive Healthcare can lead to new advancements.

As referenced in https://www.ncbi.nlm.nih.gov/books/NBK537222/ [Prevention Strategies Lisa A. Kisling; Joe M Das.] – Primary prevention consists of measures aimed at a susceptible population or individual. Secondary prevention emphasizes early disease detection, and its target is healthy-appearing individuals with subclinical forms of the disease. Tertiary prevention targets both the clinical and outcome stages of a disease.

Analyzing these 3 preventive healthcare areas from the ‘Data and Intelligent Edge IoT Lens’, it is apparent that the commonality is gathering, processing, and providing good quality round-the-clock granular data to most sophisticated ML, DL algorithms can definitely transform this area of healthcare transformation.

Our advancing society needs blend of medical and technology research implemented in a way to foster growth, scalability, improvements at lower cost and implementation cycles. These de-coupled solutions are easy to implement and promote wider Healthcare ecosystem in our connected social network.

References: 

https://www.ncbi.nlm.nih.gov/books/NBK537222/ [Prevention Strategies Lisa A. Kisling; Joe M Das.]

Congratulations to the Recipients of the 2022 EdgeX Awards!

By Blog, EdgeX Foundry

By Jim White, outgoing EdgeX Foundary TSC Chair

Each year since its founding, EdgeX Foundry awards at least four members of its contributing community with Contribution and Innovation awards.  On this fifth anniversary of the project’s founding, we honored seven distinguished engineers for their efforts on the project.

Innovation Award

Presented to individuals who have provided the most innovative solution to the open-source project over the past year

Byron Nevis and Jim Wang (both from Intel) designed and implemented the new “Delayed Start Services” security capability which is an innovative way to handle providing security tokens to services that start after the EdgeX security framework has started and already handed out tokens to all the known services.  Bryon and Jim have led most EdgeX security efforts over the past two years.  But this year, they provided some real innovation around securely storing secrets, distributing secrets, and making secrets available to other services.  Their innovation will allow adopters to add new device services and application services to EdgeX over time and as use cases demand without requiring a restart of the system.

Anthony Casagrande and Marc Fuller (both from Intel) have been instrumental in Intel’s use of EdgeX to show how it can be a platform in support of retail edge use cases.  Anthony/Marc’s work has provided both a device service and an application service to ingest and use RFID information via the LLRP (Low Level Reader Protocol) which is used in bar code reading equipment found in many retail store locations.  In addition to their inventions of these ingesting and using services, Anthony and Marc have found (and in some cases fixed) a number of bugs and have identified many needed features (submitting more than 25 Github issues) that real world adopters of the platform need.

Emilo Reyes (again from Intel – there seems to be a theme here!) has been a contributor to the EdgeX DevOps team for the last few years and has been a vital part of making the EdgeX community a better, more streamlined community. Emilio has passion for quality and with his experience around unit testing, has contributed hundreds of tests for our Jenkins global pipeline libraries providing us continuous confidence in our ability to deliver quality code. Emilio also has a passion for automation and has been a driving force behind much of our GitHub automation for EdgeX.   For instance, he created automated management of GitHub labels and milestones from a central repository, greatly reducing the number of repetitive tasks needed to manage labels/milestones across 20+ repositories. 

Contribution Award

Recognizes individuals who have contributed leadership and helped EdgeX Foundry advance and continue momentum in the past year.

 

Iain Anderson (from IOTech Systems) – has been a solid contributor, working group leader, and architect/thought leader since the founding of EdgeX in 2017.  As Device Service chairman, he has overseen several releases (major and minor) and is currently responsible for 11 active EdgeX device services and helping to usher in 4 more that are in active development.  He is the project’s first and foremost authority in C development and personally handles most of the C device service and SDK development.  Iain has over 530 commits to the project (almost 50K lines of code) which puts him #6 all time on the project.  He is also #7 in all time Pull Request submissions for the project.  He is a quiet, steadfast, never-a-complaint contributor that has championed many of the project’s advances such as device service and device profile simplifications, message bus communications from device services, device filtering, and future device service record and replay features.

 

Siggi Skulason (from Canonical) – updated and significantly improved the EdgeX CLI tool over the course of the last two release cycles.  Importantly, Siggi upgraded the tool from the V1 APIs to the V2 APIs, added support for all the service endpoints (versus a small subset selection of APIs), made the CLI available as a snap, removed a significant amount of technical debt, and improved the products help and documentation.  

 

I am happy to honor and call out these gentlemen for their efforts.  I don’t know of too many open-source projects that go to honor and thank its contributors with awards like this.  To be nominated and then selected by your peers – especially of the caliber of the EdgeX engineering community – is such a great recognition of their work.  Congratulations Bryon, Jim, Anthony, Marc, Emilo, Iain and Siggi.  Jobs well done.

You can view the Awards presentation here:

 

Thank You EdgeX

It’s been a productive few months – one release out, another planned and being worked on, and a time to shell out some well earned “kudos”.  Before I go, I want to let the community know  I am stepping aside from my role as TSC chair, and a new set of leaders are stepping up to take EdgeX into its future – and a bright future it has.

About a month after I joined Dell Technologies in 2015, I was handed the task of finding an IoT software platform to put on our new brand of gateways.  EdgeX began life on my kitchen island with an idea, an architecture and a small bit of code.  With the support of the company, some great leaders, and a collection of some of the brightest engineers I have ever worked with, my work was expanded on, productized and launched as the edge software you know today.  For the past seven years (almost to the day), EdgeX has been at the center of my professional working life (and my wife would probably add that it included much of my personal life).  Creating it, taking it into open source, working with the Linux Foundation to make it available and known, working at IOTech to commercialize the idea, and leading this wonderful community has been the highlight of my career.  It has allowed me to travel the world, meet so many amazing people, be a part of an incredible creative process, and watch something I started get used to create solutions that help people all over the globe.  EdgeX has exceeded even my wildest dreams.  It’s just hard to wrap my brain around it even today.  I am no Einstein.  But if you have an idea (even a moderately good idea), find some amazing people around you that can help turn the idea into reality, and you can catch lightning in a bottle.

I would need a separate blog post to thank everyone I owe for this experience and the success of EdgeX.  That is not an exaggeration.  “Thank you” is not enough but to the EdgeX community, people I worked with at Dell and those in my current home of IOTech Systems, I hope you take it as a small down payment for all I owe you.

I’ll close by suggesting that if anyone ever offers you the chance to work on, let alone start, an open-source project – jump at the opportunity.  You will be better for the experience.  I’ll paraphrase Winston Churchill – many forms of software development have been tried and will be tried in this world.  No one pretends that open-source development is perfect or all-wise.  Indeed, it has been said that open-source development is the worst form of software development except for all other forms that have been tried.  

EdgeX – small at the edge, but forever big in my heart.

EdgeX Foundry Issues Bug Fix Release (v2.1.1) of its EdgeX Jakarta Release

By Blog, EdgeX Foundry
The EdgeX Foundry project, a highly-scalable and flexible open source framework that facilitates interoperability between devices and applications at the IoT edge, issued a bug fix release (version 2.1.1) of the EdgeX Jakarta release.  Importantly, as Jakarta is under long-term-support (LTS), this new bug fix release addresses a critical Common Vulnerabilities and Exposures (CVE) issue.  Adopters using the Jakarta LTS release should upgrade immediately to this bug fix release.  The CVE is documented on the project’s GitHub site.  In addition, this bug fix release also addresses some less critical bugs that were identified and fixed through the Kamakura release cycle.  Details on what is in version 2.1.1 can be found on the project’s Wiki site.
All of the fixes in this Jakarta dot release are already available in the Kamakura release (the latest, but non-LTS, release from EdgeX).  Adopters of Kamakura do not need to make any changes as the CVE and other bug fixes are already part of the latest EdgeX release.

Calling all Edge App Developers! Join the ETSI/LF Edge Hackathon

By Akraino, Blog, EdgeX Foundry, LF Edge

We’re partnering with ETSI ISG MEC to host a Hackathon to encourage open edge developers to build solutions that leverage ESTI MEC Services APIs and LF Edge (Akraino) blueprints. Vertical use cases could include Automotive, Mixed and Augmented Reality, Edge Computing and 5G, and more. Teams are highly encouraged to be creative and propose to develop solutions in additional application verticals. 

Here’s how it works:

  • Participants will be asked to develop an innovative Edge Application or Solution, utilizing ETSI MEC Service APIs and LF Edge Akraino Blueprints.
  • Solutions  may include any combination of client apps, edge apps or services, and cloud components.
  • The Edge Hackathon will run remotely from June to September with a short-list of best teams invited to complete with demonstrations and a
  • Hackathon “pitch-off” at the Edge Computing World Global event in Santa Clara, California Silicon Valley on October 10th-12th

Submissions are due 29th June 2022.  More details, including how to register, are available here.

Additional background information:

Edge Computing provides developers with localized, low-latency resources that can be utilized to create new and innovative solutions, which are essential to many application vertical markets in the 5G era.

  • ETSI’s ISG MEC is standardizing an open environment that enables the integration of applications from infrastructure and edge service providers across MEC (Multi-access Edge Computing) platforms and systems, which offers a set of open standardized Edge Service APIs to enable the development and deployment of edge applications at scale.
    • Teams will be provided with a dedicated instance of the ETSI MEC Sandbox for their work over the duration of the Hackathon. The MEC Sandbox is an online environment where developers can access and interact with live ETSI MEC Service APIs in an emulated edge network set in Monaco, which includes 4G, 5G, & WiFi networks configurations, single & dual MEC platform deployments, etc.
  • LF Edge’s Akraino project offers a set of open infrastructure and application Blueprints for Edge, spanning a broad variety of application vertical use-cases. Each blueprint offers a high-quality full-stack solution that is tested and validated by the community.

However, teams are not required to use a specific edge hosting platform or MEC lifecycle management APIs. Developers may use any virtualization environment of their choosing. 

Submissions are due 29th June 2022.  More details, including how to register, are available here.

What’s Next for EdgeX: Onto Levski

By Blog, EdgeX Foundry

By Jim White, EdgeX Foundry TSC chair

May was a busy month at EdgeX Foundry.  EdgeX released version 2.2, Kamakura in the middle of May (details here) and went straight into planning our fall release – code named Levski.  We also selected our 2022 EdgeX Award winners as well, and I’ll be posting a follow-up  to congratulate them and speak to some of their efforts.

Levski

First, what is the next release of EdgeX going to be about?  It is slated to be released in November of 2022.  It will, in all likelihood be another minor dot release (version 2.3 to be precise) that is backward compatible with all EdgeX 2.x releases.  The Levski release will also not be an LTS release.  Jakarta remains the first and only LTS for EdgeX for now (more on that below).  By the way, in case you are wondering where the name Levski (or the name of any EdgeX release) comes from, a top contributor to our project is selected in each release cycle to name an upcoming release.  Levski is named after one of our CLI developers’ favorite home-country (she is from Bulgaria) mountain peak.

You will see the words “likely” and “anticipate” show up a lot in this post because a lot can happen in the span of six months when building open-source software.  These caveats are there to remind the reader that what is planned is not set in stone – so if you are an adopter/user of EdgeX, design accordingly.

Major Features

Two of the most important features that we are looking to land in the Levski release are:

  • North-to-south message bus communications
  • Control plane (aka system management) events

North-to-south messaging will set up the means for a 3rd party application or cloud system to use MQTT to communicate with EdgeX’s command service and trigger an actuation or data fetch command all the way through to the devices/sensors.  

Today, communications going from north to south in EdgeX are accomplished via REST.  Therefore, things are not really asynchronous and there isn’t the opportunity to set the quality of service (QoS) of the communications in these instances.  Levski will allow adopters of EdgeX to use messaging to trigger actions and communicate data needs.  This compliments what is already available in EdgeX which is the ability to use messaging from south to north.  The design for this feature was finalized in this past Kamakura release cycle.  You can see the design document for more details.

The second major feature to highlight in Levski is control plane events (CPE) or also known as system management events.  This feature will allow EdgeX to send important events to would-be listeners (could be other EdgeX services, could be 3rd party subscribers) that something (an event) has happened in EdgeX.  Examples of control plane events are that a new device/sensor was provisioned or a new profile was uploaded.  Control plane events could also report on micro service issues – such as not having access to a database it needs.  Each EdgeX micro service will define its own control plane events, however in this release, it is anticipated that control plane events will first be tried with core metadata.

Other Features and Fixes

More Metrics

During the Kamakura release cycle, we implemented a new beta metrics/telemetry feature.  This feature allows any service to report (via message bus) on telemetry from the service that allows for better monitoring and management of EdgeX.  Telemetry such as how many events have been persisted, or how long does it take for a message to be processed in an app service can now be collected and published by EdgeX Metrics.  In this release cycle, we plan to proliferate metrics across all services (it was only in a few services for Kamakura) and take the feature out of beta status.

Experiment with MQTT authentication in service-to-service communications

Today, EdgeX has an API gateway to protect the REST APIs.  We also secure external message bus communications, but there is nothing that secures message bus communications internally.  In Levski, the community is going to be exploring possible solutions for securing MQTT message traffic.  We plan to explore and prototype with OpenZiti – a zero trust open-source project that provides an overlay network for secure communications between services and may even allow us to provide an alternative to our API gateway (Kong today).

Unit of Measures

In this past release cycle, we spent some time designing a solution that would allow units of measure to be associated to all of the edge sensor data collected.  There are many “standard” units of measure in the world.  We did not pick one, but allowed the adopter to pick / use the units of measure they want associated to their data.  In the Levski release, we hope to implement the design we formalized in the last release.  See our design documentation for more details.

Miscellaneous

The community is seeing more efforts by users/adopters to deploy EdgeX in non-containerized environments and wanting to build EdgeX for other environments (ARM32, RISC-V, etc.).  There is also a growing desire on the part of adopters to be able to have versions of our micro services that don’t include dependencies or modules that aren’t being used (for example, not including 0MQ when not using 0MQ for communications or not including security modules in a deployment that is not using EdgeX security features).  Therefore, the project is looking to provide more “build” from scratch options that remove unnecessary libraries, modules, etc. in environments where these features are not needed.  We call them “lite builds” and they should be more prevalent in Levski.

A growing demand for NATs as a message bus implementation in EdgeX will have the community doing some research and experimentation with NATS in this release cycle.  It is unlikely that full-fledged NATS message bus support comes out of this release, but we should begin to understand if NATs can be used as a message but implementation for our messaging abstraction and know the benefits of NATs over Redis Pub/Sub or MQTT for our use cases.

As you hopefully can see, Levski, while considered a minor release, will likely include a number of useful new features.

EdgeX 3.0

As part of the planning cycle, the EdgeX community leadership also considered the question of the next major release (EdgeX 3.0) and next LTS release.  By project definition, major releases are reserved for significant new features and inclusion of non-backward compatible changes.  We have tentatively slated the spring of 2023 as the target time for EdgeX 3.0.  We have been collecting a number of fixes and features that will require non-backward compatible changes.  We think the time will be right to work on these in the Minnesota release (code name for the spring 2023 release).  If all goes to plan, an LTS release will follow that in the fall of 2023.  The Napa release (code name for the fall 2023 release) would be the community’s second LTS release.  The 3rd major release and 2nd LTS release would fall exactly two years from our 2nd major release (Ireland in spring 2021) and first LTS (Jakarta in fall 2021).

Adopters should take some comfort in the fact that the project is healthy, stable and is looking out to the future.  As always, we welcome input and feedback on how EdgeX is supporting your edge/IOT solutions and what we can do better.

EDGE in the Healthcare Nutrition Industry

By Blog

By LF Edge Community members Utpal Mangla (Industry EDGE Cloud – IBM Cloud Platform);  Atul Gupta (Lead Data Architect – IBM); and  Luca Marchi (Industry EDGE and Distribute Cloud – IBM Cloud Platform)

Diet and Nutrition plays a vital role in healthcare and often it is still left behind by medical practitioners, doctors, nurses, and alternative medical care professionals. Whether patient is recovering from regular sickness, injuries, surgeries, or chronic illness – all of them need special care for diet and nutrition provided to the patients. The need is to provide enough nutrition at pre-determined frequencies for faster recovery and making sure the normalcy returns for the most patients in moderate time and at optimal expense. But the diet and nutrition guidance provided is either very generic or not monitored and adjusted as per patients’ vitals and recovery progression. 

These traditional mechanisms of feeding the health, diet, nutrition tracking data to medical practitioners is one-way mechanism and siloed decision making is based on this disparate data and not tied up for common benefits of the patients.

With the ongoing digital transformation of the healthcare, there is organic growth of edge devices in the hands of patients, healthcare staff such as fit-bit, cellphones, nutrition scales, smart kitchen, and bed-care devices, etc. The questions are – Where do we take it from here? What do we do with this explosion of edge data? Are we creating another set of data-silos?

Edge computing has the solutions for most of these problems and it can provide connectivity to use this data effectively and efficiently. This can converge all the data silos from traditional devices, healthcare facilities, human diet, and nutrition data into common repository such as ‘Data producers at Edge’, which can feed the data into cloud computing environments. The specialized healthcare cloud computing environments are now available, but they lack the data ingestion components. 

The ‘Data producers at Edge’ ingest the healthcare data into cloud computing environments from the Edge devices, healthcare facilities, et al completing the full cycle of data usage. This complete data cycle can now start benefiting patients, their families and as much gain efficiency for healthcare staff and facilities. Hospitals and alternative health professionals can start treating patients remotely using this new paraphernalia of devices, solutions, and inter-connectivity. 

These Data producers have rich data about patients’ daily health, vitals, physical vicinities, living conditions, walk-score, mobility, and assistance provided, etc. The net impact of using this data in combined and constructive way can not only open new horizons for healthcare but can start a new journey with Edge transformation which is yet to be realized. There is a potential of new industry disruptor in this area by leveraging benefits of Edge, Cloud computing, IoT devices, Patient Literacy, et al. The combination is self-serviced components and interconnectivity which can expand and scale on demand, as needed and provide solutions to areas of high demand and growth. It is now known that many healthcare areas can only be scaled and gain service efficiency by technology solutions and not by putting more healthcare facilities and professionals. Also, the traditional diet and nutrition methods have always played effective role in patient recovery, which can yield accurate, efficient, and robust healthcare solutions if used in conjunction with Edge and IoT advancements.

This full cyclic approach will tie together the Diet and Nutrition aspects to other healthcare areas, components, and capabilities. The basics of patient’s recovery progression can ultimately start to play its role in more connected manner and predictive care can replace the reactive care approach. 

The Edge data can be used to generate patient analytics and align it to diet and nutrition data to come up with new predictive care capabilities. The health care staff can adjust, re-calibrate the exercises based on existing and proposed diet and nutrition for the patients. This can even extend into improving the supply-chain of the products and services needed for the healthcare industry.

The diet and nutrition data, combined with sophisticated cloud compute can yield better and improved predictive care for the patients and move to new era in Healthcare Digital Edge Transformation

EdgeX Foundry Turns 5 Years Old & Issues its 10th Release

By Blog, EdgeX Foundry

By Jim White, EdgeX Foundry Technical Steering Committee Chair

EdgeX Foundry, an LF Edge project, turned five years old in April and celebrated with its 10th release!

Today, the project announced the release of Kamakura – version 2.2 of the edge/IoT platform.  EdgeX has consistently released two versions a year (spring and fall) since its founding in 2017.  Looking back to the founding and announcement of the project at Hannover Messe 2017, I would be lying if I was to say I expected the project to be where it is today.

Many new startup businesses don’t last five years. For EdgeX to celebrate five years, steadily provide new releases of the platform each year, and continue to grow its community of adopters is quite an achievement.  It speaks both to the need for an open edge / IoT platform and the commitment and hard work of the developers on the project.  I am very proud of what this community has accomplished.

We’ll take a closer look at EdgeX highlights over the past five years in an upcoming blog post, so for now, let’s dive into the Kamakura release. 

 

Here’s an overview of what’s new:

Kamakura Features

While this “dot” release follows on the heels of the project’s first ever long-term support release (Jakarta in the fall of 2021), the Kamakura release still contains a number of new features while still maintaining backward compatibility with all 2.x releases.  Notably, with this release, EdgeX has added:

  • Metrics Telemetry collection: EdgeX is about collecting sensor/device information and making that data available to analytics packages and enterprise systems in a consistent way so it can be acted on.  However, EdgeX had only minimal means to report on its own health or status.  An adopter could watch EdgeX service container memory or CPU usage or use the “ping” facility to make sure the service was still responsive, but that is about it.  In the Kamakura release, new service level metrics can be collected and sent through the EdgeX message bus to be consumed and monitored.  Some initial metrics collection is provided in the core data service (ex: number of events and reading persisted) for this release, but the framework for doing this system wide is now in place to offer more in the next release or allow an adopter to instrument other services to report their metrics telemetry as they see fit.  The metrics information can be easily subscribed to by a time series database, dashboard or custom monitoring application.

 

  • Delayed Start Services:  When EdgeX is running with security enabled, an initialization service (called security-secretstore-setup) provides each EdgeX micro service with a token which is used to access the EdgeX secrets store (provided by Vault).  These tokens have a time to live (TTL) which means if they were not used or renewed, they expired.  This created problems for services that may need to start later – especially those that are going to connect to future sensors/devices.  Furthermore, not all EdgeX services are known when the platform initializes.  An adopter may choose to add new connectors (both north and south) all the time to address new needs.   These types of issues and others often meant that adopters often had to shutdown EdgeX and restart all of EdgeX in order to provide new security tokens to all services.  In Kamakura, this issue has been addressed with a new service that uses mutual authentication TLS and exchanges a SPIFFE X.509 SVID for getting secret store tokens.  This new service allows a service to get or renew a token used to access the EdgeX secrets store anytime and not just at the bootstrapping / initialization of EdgeX as a whole.

 

  • New Camera Device Services:  While EdgeX somewhat supported connectivity to ONVIF cameras through a camera device service, the service was incomplete (for example not allowing the camera’s PTZ capability to be accessed).  With Kamakura, EdgeX will now have two camera device services.  A new ONVIF camera device service is more complete and tested against server popular camera devices.  It allows for PTZ and even the discovery of ONVIF compliant cameras.  A second camera service – a USB camera service – will help manage and monitor simple webcams.  Importantly, EdgeX will, through the USB camera service, be able to get a USB camera’s video stream to other packages (such as an AI/ML engine) to incorporate visual inference results into the EdgeX data sensor fusion capability.

 

  • Dynamic Device Profiles: in prior releases, device profiles were considered mostly static.  That is, once a device profile was used and associated to a device or any other EdgeX object like an event/reading, it was not allowed to change.  One could not, for example, have an empty device profile and add device resources (the sensor points collected by a device service) later as more details of the sensor or use case emerged.  With the Kamakura release, device profiles are much more dynamic in nature.  New resources can be added all the time.  Elements of the device profile can change over time.  This allows device profiles to be more flexible and adaptive to the sensors and use case needs without having to remove and re-add devices all the time.

 

  • V2 of the CLI:  EdgeX has had a command line interface tool for several releases.  But the tool was not completely updated to EdgeX 2.0 until this latest release.  For that matter, the CLI did not offer the ability to call on all 100% of the EdgeX APIs.  With Kamakura, the CLI now provides 100% coverage of the REST APIs (any call that can be done via REST can be done through the CLI) in addition to making the CLI tool compatible with EdgeX 2.0 instances.  Several new features were added as well to include tab completion, use of the registry to provide configuration, and improved result outputs.

The EdgeX community worked on many other features/fixes and behind the scenes improvements to include:

  • Updated LLRP/RFID device service and application services
  • Added or updated GPIO and CoAP services 
  • Ability to build EdgeX services on Windows platform (providing optional inclusion of ZMQ libraries as needed)
  • CORs enablement
  • Added additional testing – especially around the optional use of services
  • Added testing to the GUI
  • Optimized the dev ops CI/CD pipelines
  • Kubernetes Helm Chart example for EdgeX
  • Added linting (the automated checking of source code for programmatic, stylistic and security issues) part of the regular build checks and tests on all service pull requests
  • Formalized release and planning meeting schedule
  • Better tracking of project decisions through new GitHub project boards

Tech Talks

When EdgeX first got started, we provided a series of webinars called Tech Talks to help educate people on what EdgeX is and how it works.  We are announcing that a new Tech Talk webinar series will begin May 24 and run weekly through June.  The topic list includes:

  •   May 24 – Getting Started with EdgeX
  •   June 7 – Build an EdgeX Application Service
  •   June 14 – Build an EdgeX Device Service
  •   June 21 – Creating a Device Profile
  •   June 28 – Getting started with EdgeX Snaps

These talks will be presented by distinguished members of our community.  We are going to livestream them through YouTube at 9am PDT on the appointed days.  These new talks will help provide instruction in the new EdgeX 2.0 APIs introduced with the Ireland release.  You can register for the talks here:

What’s Next: Fall Release – “Levski”

Planning for the fall 2022 release of EdgeX – codenamed Levski – is underway and will be reported on this site soon.  As part of the Kamakura release cycle, several architectural decision records were created which set the foundation for many new features in the fall release.  This includes a north-south messaging subsystem and standardization of units of measure in event/readings. 

 EdgeX is 5, but its future still looks long and bright.

 

Deep Learning Models Deployment with Edge Computing

By Blog

By Utpal Mangla (IBM), Luca Marchi (IBM), Shikhar Kwatra (AWS)

Smart Edge devices across the world are continuously interacting and exchanging information through machine-to-machine communication protocols. Multitude of similar sensors and endpoints are generating tons of data that needs to be analyzed in real-time used to train deep complex learning models. From Autonomous Vehicles running Computer vision algorithms to smart devices like Alexa running Natural language processing models, the era of deep learning has widely extended to plethora of applications. 

Using Deep learning, one can enable such edge devices to aggregate and interpret unstructured pieces of information (audio, video, textual) and take ameliorative actions, although it comes at the expense of amplified power and performance measurements. Since Deep learning resources require huge computation time and resources to process streams of information generated by such edge devices and sensors, such information can scale very quickly. Hence, bandwidth and network requirements need to be tackled tactfully to ensure smooth scalability of such deep learning models. 

If the Machine and deep learning models are not deployed directly at the edge devices, these smart devices will have to offload the intelligence to the cloud. In the absence of a good network connection and bandwidth, it can be a quite a costly affair. 

However, since these Edge or IoT devices are supposed to run on low power, deep learning models need to be tweaked and packaged efficiently in order to smoothly run on such devices. Furthermore, many existing deep learning models and complex ML use cases leverage third party libraries, which are difficult to port to these low power devices. 

The global Edge Computing in Manufacturing market size is projected to reach USD 12460 Million by 2028, from USD 1531.4 Million in 2021, at a CAGR of 34.5% during 2022-2028. [1]

Simultaneously, the global edge artificial intelligence chips market size was valued at USD 1.8 billion in 2019 and is expected to grow at a compound annual growth rate (CAGR) of 21.3% from 2020 to 2027. [2]

Recent statistical results and experiments have shown that offloading complex models to the edge devices has proven to effectively reduce the power consumption. However, pushing such deep learning models to the edge didn’t essentially meet the latency requirements. Hence, offloading to edge may still be use case dependent and may-not work for all the tasks involved at this point. 

We have to now build deep learning model compilers capable of optimizing these models into executable codes with versioning on the target platform. Furthermore, it needs to be compatible or go in-line with existing Deep learning frameworks inclusive of but not limited to MXNet, Caffe, Tensorflow, PyTorch etc. Lightweight and low power messaging and communication protocol will also enable swarms of such devices to continuously collaborate with each other and solve multiple tasks via parallelization of tasks at an accelerated pace. 

For instance, TensorFlow lite can be used for on-device inferencing. First, we pick an existing versioned model or develop a new model. Then, the TensorFlow model is compressed into a compressed flat buffer in the conversion stage. The compressed tflite file is loaded into an edge device during the deployment stage. In such manner, various audio classification, object detection and gesture recognition models have been successfully deployed on the edge devices. 

Hence, if we migrate the deep learning models with specific libraries and frameworks (like tensorflow lite or ARM compute library for embedded systems) can be optimized to run on IoT devices. In order to scale it further with efficiency, first, we need to directly compile and optimize deep-learning models to executable codes on the target device and we need an extremely light-weight OS to enable multitasking and efficient communications between different tasks.

References:

  1. https://www.prnewswire.com/news-releases/edge-computing-market-size-to-reach-usd-55930-million-by-2028-at-cagr-31-1—valuates-reports-301463725.html
  2. https://www.grandviewresearch.com/industry-analysis/edge-artificial-intelligence-chips-market

 

IoT Enabled Edge Infusion

By Blog

By Shikhar Kwatra, Utpal Mangla, Luca Marchi

The sheer volume of information being processed and generated by Internet of things enabled sensors has been burgeoning tremendously in the past few years. As Moore’s law is still valid providing an indication of number of transistors in an integrated circuit doubling roughly every two years, growing ability of edge devices to handle vast amounts of data with complex designs is also expanding on a large scale. 

Most current IT architectures are unable to compete with the growing data volume and maintain the processing power to understand, analyze, process and generate outcomes from the data in a quick and transparent fashion. That is where IoT solutions meets Edge Computing. 

Transmitting the data to a centralized location across multiple hoops, for instance, from the remote sensors to the cloud involves additional transport delays, security concerns and processing latency. The ability of Edge architectures to move the necessary centralized framework directly to the edge in a distributed fashion in order to make the data to be processed at the originating source has been a great improvement in the IoT-Edge industry.

As IoT projects scale with Edge computing, the ability to efficiently deploy IoT projects, reduce security to the IoT network, and adding of complex processing with inclusion of machine learning and deep learning frameworks have been made possible to the IoT network. 

International Data Corporation’s (IDC) Worldwide Edge Spending Guide estimates that spending on edge computing will reach $24 billion in 2021 in Europe. It expects spending to continue to experience solid growth through 2025, driven by its role in bringing computing resources closer to where the data is created, dramatically reducing time to value, and enabling business processes, decisions, and intelligence outside of the core IT environment. [1]

Sixty percent of organizations surveyed in a recent study conducted by RightScale agree that the holy grail of cost-saving hides in cloud computing initiatives. Edge AI, in contrast, eliminates the exorbitant expenses incurred on the AI or machine learning processes carried out on cloud-based data centers. [2]

Edge is now widely being applied in a cross-engagement matrix across various sectors:

  1. Industrial – IoT devices and sensors where data loss is unacceptable
  2. Telecommunication – Virtual and Software Defined solutions involving ease of virtualization, network security, network management etc.
  3. Network Cloud – Hybrid and Multi-cloud frameworks with peering endpoint connections, provisioning of public and private services requiring uptime, security and scalability
  4. Consumer & Retail framework – Inclusion of Personal Engagement devices, for instance, wearables, speakers, AR/VR, TV, radios, smart phones etc. wherein data security is essential for sensitive information handling 

Since not all the edge devices are powerful or capable of handling complex processing tasks while maintaining an effective security software, such tasks are usually pushed to the edge server or gateway. In that sense, the gateway becomes the communications hub performing critical network functions inclusive of but not limited to data accumulation, sensor data processing, sensor protocol translation and understanding prior to the gateway forwarding the data to the on-premise network or cloud. 

From Autonomous vehicles running different Edge AI solutions to actuators with WIFI or Zigbee with the ability to connect to the network, with increased complexity of fusion of different protocols, different edge capabilities will continue to surface in coming years.

References: 

[1] https://www.idc.com/getdoc.jsp?containerId=prEUR148081021

[2] https://www.itbusinessedge.com/data-center/developments-edge-ai/