James Butcher

I am delighted to announce the release of the latest and greatest version of EdgeX Foundry the open source edge data platform. Version 3.0 is our most significant upgrade to date and I firmly believe will bring much value to edge solution developers in a variety of industrial sectors.

As the EdgeX TSC chair and product manager of IOTech’s commercial EdgeX-based solutions, I’d like to explain what EdgeX V3 brings and describe how the platform continues to be the key framework upon which companies rely when developing their commercial edge software solutions.

A jump of major version is significant for EdgeX, not only because it indicates a new set of key features for its user base, but also because it shows the mature, yet evolutionary outlook of the base platform and the associated commercial edge products that are available in the ecosystem.

EdgeX Reminder

EdgeX Foundry is an open source edge data platform, managed and hosted under the Linux Foundation Edge umbrella. More specifically, EdgeX is a highly flexible and scalable architecture that allows easy interoperability between edge devices and applications. It is made possible thanks to an ecosystem of community collaborators (including Intel, IOTech, Canonical, Eaton, Beechwoods and many others) representing a variety of industries.

Minnesota

To help in its identification, each release of EdgeX is provided a codename based on a geographical location. The previous version was named Levski (located in Bulgaria). The next stopping point on our virtual world tour is Minnesota! Aptly named, in part for being a key industrial center of the United States, EdgeX Minnesota helps to further serve the needs of OT/IT integration at the edge.

The major jump in version number lets us make more significant updates to the framework and allows us the freedom to make changes that are otherwise prohibited by our minor version compatibility rules. Of course, we try to be backwards compatible where possible, but after two years of V2 minor releases, there are some key updates and usability benefits we can now bring in…

Easier, Common Configuration

The main theme of Minnesota is usability. In particular, the way the user configures EdgeX has been much simplified and improved. Version 3.0 of EdgeX introduces a common configuration pattern for the EdgeX microservices. Since many config options (logging, telemetry, security, database and message bus settings) apply across multiple microservices, we’ve added the ability to configure these in a single common location. Some microservices are likely to have common config requirements, e.g., the southbound device services or northbound application services, so we’ve provided a layered design where users can configure settings at their chosen level.

This will save developers and deployers of EdgeX systems a lot of time and reduce maintenance effort. It will be much easier to make config changes, rerun the system and be confident that the settings have all taken effect appropriately. Take a look at the latest EdgeX docs for the details.

Reduced Config Formats

The jump in major version has also allowed us to reduce the number of different config file formats in EdgeX. Removing TOML and using only YAML and JSON going forward helps reduce what a new user has to learn. YAML and JSON can be derived from each other, so we let users pick their favorite and work with that. Again, usage of the platform becomes easier and more maintainable.

Service Authentication

Another big feature for 3.0 is the addition of microservice authentication within EdgeX. When run in secure mode, the microservices now require a validated authentication token before they are allowed to communicate. Thanks to the efforts of the EdgeX Security Working Group, this is all built into the platform with tokens issued by the Secret Store service. The security advancements here also allow version 3 to switch to a much lighter-weight API Gateway service than was used previously, which helps a lot with our ongoing effort to minimize the footprint of the platform.

Other V3 Updates

Of course, we also have V3 versions of the EdgeX APIs. We do have some minor changes there including updates to help with the automatic discovery of devices, but the APIs are mature so there aren’t the major updates we had with the previous major jump. You can check out the full set of changes in the EdgeX V3 migration guide.  Full release notes are here.

Using EdgeX V3 and Joining in

We’re expecting that the next version after this (3.1 or Napa) planned for Q4 this year, will become the new Long Term Support (LTS) version of EdgeX. Those users wishing to jump from the previous LTS (2.1 or Jakarta) should start to become familiar with the new features. There are some breaking changes, so we encourage you to start to get to know V3 sooner rather than later. The features put into EdgeX Minnesota will serve as the basis for other features for the next few years. For example, using URLs to point to configuration and profiles that could come from anywhere and be shared is only possible because of the common configuration feature added now.

So please do go ahead and download EdgeX V3. A good place to get going is the Getting Started Guide and the lively EdgeX discussions board is a great place to chat and leave feedback.

EdgeX Foundry now fully embraces decoupled message bus communication within the platform

I am delighted to announce today the availability of the EdgeX Foundry 2.3 release which is codenamed Levski. This is the project’s 11^th official release since its inception in 2017 and includes some significant new features and benefits to users that I’ll explain in this blog.

Having been elected as the chair of the EdgeX Technical Steering Committee (TSC) earlier this summer, it’s great to be able to announce the news of this release but it really is the technical expertise and dedication of the EdgeX development team that helps bring these releases to the wider community. Thanks again for everyone’s effort here. Great to be part of a group of many different companies and individuals working together to make great open source edge software.

What is Levski?

First let me give mention to the Levski codename. As you may know, each EdgeX release is named after a certain place or location in the world, with the specific place chosen each time significant contributors to the project. This version was named by two long term EdgeX contributors, Diana Atanasova and Malini B

handaru, both from VMware. For version 2.3 and the letter “L”, we come back over to Europe because Levski is a large mountain in the beautiful European country of Bulgaria. Bulgaria is also Diana’s homeland so it’s nice to be able to recognize that with the naming of this release.

New in EdgeX 2.3 – More about the Message Bus

Perhaps the biggest single new feature is the enhancement to support the delivery of commands via the EdgeX message bus.

We’ve previously made great strides in EdgeX V2 by delivering data from the southside (from devices and sensors) to the northside (to the core and application layers) via an internal message bus. This release also adds the support in the other direction, i.e., from the northside (the application layers and core layers) down to the southside (the devices and sensors) on the same message bus. Previously the southbound communication was exclusively via REST. Moving to support message bus-based communication in both directions is a big advancement and brings key benefits in terms of reduced latency and increased scalability. The asynchronous communication and the QoS-based control that you get from the message bus implementations that you can choose adds delivery guarantees and retransmissions of messages as needed.

More Run-Time Data

Another key area of development for Levski has been the focus on providing EdgeX users with more live information about how the system is running. EdgeX 2.3 adds System or “Control Plane” Events that can provide live updates as to what is happening. For example, users can receive notifications that new devices are added or that there has been a network disconnection from a specific device.

Somewhat related to System Events are the Telemetry Metrics. In contrast to events though, the metrics provide numeric information relating to how the platform is operating. Examples include the number of data readings that are persisted by core data or the number of secrets or tokens that are stored. Building of what was delivered previously, Levski adds more metrics across all of the services.

All of this information can be collected and reported however the user sees fit. In addition, the System Events and Telemetry Metrics mechanisms are available for users to add their own metrics as needed.

Many other updates and enhancements

There are many other new additions in this last release cycle including:

• Availability of NATS as alternative implementation of the internal EdgeX Message Bus. NATS is a popular and lightweight protocol with native delivery of EdgeX messages and potential advantages in high availability (HA) use cases
• Authenticated access to the MQTT message bus
• Securing of the Consul registry service with access tokens
• Passing status at the Open Source Security Foundation (OpenSSF)
• Initial construction of the EdgeX STRIDE threat model
• Improving the EdgeX development process with a new Use Case Requirements (UCRs) phase in the design procedure

See the release notes here for full details of what the Levski release provides.

New adopters and use cases for EdgeX

Running as a mature, stage 3 Linux Foundation project, there are now many users and adopters of EdgeX technology around the world. That includes users who download and deploy the open source EdgeX code, but also users of commercial products (including ours at IOTech) that are based on EdgeX. Take a look at some of the companies who are users of EdgeX. There are also a good set of presentation videos from different adopters of the technology.

One of my personal aims as TSC chair is to help encourage the adoption and wider use of EdgeX. Thanks to Building System Integrators (BSI) who recorded a talk at a recent TSC meeting. It would be great to hear from more companies who would like to do something similar. Please do reach out to me to arrange it.

What’s coming next?

Each release marks a busy period where of course we finalize the current version, but already we are looking forward at what we can achieve in the next release. Codenamed Minnesota and expected to be version 3.0, we are looking to add new features to help with the scalable configuration of EdgeX. Tune into the Minnesota technical planning conference that we are running next week where we will scope out what we can do. As always, attendance and contributions are very welcome.

Thanks again to everyone who had a hand in this release, and we look forward to more successful releases in the future.