LF Edge

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.

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.

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:

• May 24: https://zoom.us/webinar/register/WN_c6c-4LAfRD6AJP1BQM6QeQ
• June 7-28: https://zoom.us/webinar/register/WN_hyrYdafeR5mSM5oLcM75hA

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.