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.
