EdgeX Foundry

Written by James Butcher, EdgeX Foundry Core Working Group Chair and Edge Xpert Product Manager at IOTech Systems

 Following the recent release of EdgeX Foundry version 2.1, codenamed “Jakarta”, I thought it would be useful to provide a quick update on some of the performance metrics of the platform as it has evolved over the last couple of release cycles.

This release of EdgeX is also the first long term support (LTS) edition, whereby the EdgeX community will support this version with critical fixes for major flaws or bugs. The project’s detailed testing strategy helps to provide the confidence that this version is robust and reliable – and is key to the community making those LTS statements. See here for more details about the LTS policy.

Recent EdgeX Working Group Changes

You may know that the EdgeX QA & Test Working Group was previously responsible for the creation and operation of the community’s testing strategy and its main Test Automation Framework (TAF). This summer, the QA & Test group was merged into the EdgeX Core Working group, and I was pleased to be given the opportunity to chair the new combined group.

A key part of the EdgeX Core Working Group is its commitment to testing which helps ensure the quality and robustness of the framework. An EdgeX version is only released, for example, when all key requirements are reliably tested and preferably automated as part of TAF.

EdgeX Performance Metrics 

Another key part of the EdgeX testing strategy is the recording and monitoring of performance metrics. Since EdgeX 1.1 (Fuji), we have been running dedicated performance tests with each release and producing formal performance reports that describe the findings.

I mentioned some of the performance testing advancements in my blog around the release of EdgeX 1.3 (Hanoi). We cover key points such as footprint, CPU usage and latency of data flow through the platform. 

In the last couple of cycles (Ireland and Jakarta) we are now also recording performance related to running with the EdgeX Security Services.

Please find the Jakarta Performance Report here or click on the image below. 

The data continues to show that the EdgeX microservices developed by the community are generally pretty small and lightweight. One of the EdgeX Core Services, Core Metadata, for example, has a Docker image footprint of around 17MB.

Some of the third-party services we bring in, such as the Security Services or the Registry Service are a little larger, but still the footprint of the complete EdgeX stack requires less than 1GB of disk space. Note also the microservices architecture means not all services need to be deployed in all scenarios. It’s easy to pick and choose the services needed for each use case or physical hardware capability.

So whilst quite lightweight, we are still pushing for EdgeX to be smaller and faster where possible. The next couple of EdgeX development cycles (Kamakura and Levski) are devoting time to this, but a nice reduction in Jakarta is a drop in the run-time memory usage for the API Gateway Security Service. In previous EdgeX versions, memory consumption of the complete stack was recorded as around 1GB RAM, but an optimization such as configuring the API Gateway Service to run with a specific number of worker processes, means we can be much lower than that when needed. These types of config options are invaluable in helping to tune the framework, if physical resources are a concern.

Full Commercial Support and Value Add

I also wanted to mention IOTech’s commercially supported edition of EdgeX, named Edge Xpert. Edge Xpert 2.1, based on EdgeX Jakarta, will be available very soon so stay tuned for more info. Head to the IOTech website to understand how Edge Xpert features and its technical support offerings can help users deploy the EdgeX based technology more easily.

Open Community

Finally, please feel free the join our EdgeX Core meetings where we discuss progress and other issues that need to be addressed each week. We meet every Thursday at 8am PST. You can find the meeting links on our page here. 

 

 

By Jim White, EdgeX Foundry TSC Chair

As I write this, it is Thanksgiving week in the United States.  A time for everyone to reflect, share some time with loved ones, and show appreciation for the year’s blessings.  I cannot think of a better time to also say “thank you” to the EdgeX Foundry community of volunteers.  We just released our 2nd release of the year (the Jakarta release which is our 9th release overall).  Saying “thank you” seems insufficient and I really wish there was a better way to express the gratitude I have to all the men and women that continually do such great work and allow us to consistently deliver EdgeX releases cycle after cycle. 

I have said it before but it bears repeating, I consider myself fortunate to be associated with such a great group of people that work on EdgeX Foundry – both our volunteers and those that assist from the Linux Foundation.  Co-founding the project and serving as the project’s leader has been the highlight of my career.  Importantly, it is the people that I have had a chance to meet and interact with through the project that has made the experience so wonderful.

As anyone that has the fortune to lead an open-source project will tell you, volunteers – that is the contributors to the project – are the lifeblood of the project.  If you don’t have enough volunteers or if you don’t have a community of people with great attitudes and willingness to work together to make something great, your project will soon flounder and fail.  Because of organizational or personal commitments, an open-source project must constantly seek out new contributors who also bring new ideas and energy to a project.  This is not easy and project leaders often have to play the role of cheerleader and recruiter to find people willing to part with their most precious commodities: time and knowledge.

That is why EdgeX Foundry is excited to announce a new program meant to thank those that contribute to the project and hopefully entice new contributors to spend time on the project.

As of  November, the EdgeX Developer Badge program will send a digital badge to contributors on two occasions:

1. When a contributor submits their first pull request that gets accepted and merged into the EdgeX Foundry code base (via GitHub)
2. When a contributor fixes two bugs that have been documented via GitHub issues in one of the project’s repositories

The new EdgeX Foundry Developer Badges for bug fixing (the “Bug Hunter” Badge) and first contribution (First Time Contributor Badge)

Additional badges may be awarded by the project in the future.  The badges will be automatically issued via the project’s CI/CD processes and through Credly.com.  Developers will receive an email notification from the project when they have made their badge-worthy contribution.   They will also receive an email from Credly that allows them to accept their digital badge and then share their verifiable credential on LinkedIn, Twitter or other social media platform of their choosing.  It is a small token of appreciation on the part of the project to say “thank you for your work” that also allows a contributor to post recognition of their effort to professional or personal media outlets.  In other words, it’s an official way to provide some “street cred” to our volunteers, which we hope will attract their peers and co-workers to seek the same.

To our knowledge, this is a first of its kind program for an open-source project.  If there is an open-source project out there that would like to copy our program, please feel free to reach out to me for more information.  We’d like to see more contributors in more open-source projects and if this can help, we would be happy to share what we have done.

While saying thanks, I’d like to thank Aaron Williams who was the LF Edge Developer Advocate until this summer for coming up with the initial program idea.  I’d also like to thank Ernesto Ojeda, our EdgeX Dev Ops Working Group Chairman, and his Intel DevOps team for implementing the program.  It’s another example of the great people and work found in the LF Edge and EdgeX communities.

On behalf of the EdgeX Foundry project, we wish everyone a joyous holiday season.

 

By Jim White, EdgeX Foundry Technical Steering Committee Chair

 

 

 

 

 

 

 

When you think of Ireland, most people envision bright green, fresh landscapes.  An island cleaned regularly by plentiful rain and always made new.  The Ireland name is appropriate to our latest release – which is EdgeX made fresh,  a major overhaul.  

EdgeX Foundry 2.0 is a release over a year in the making!  

This is the EdgeX community’s second major release and our 8th release overall.  Indeed, the Ireland release contains both new features and non-backward compatible (with any EdgeX 1.x release) changes.  In general, this release took a huge step to eliminate, or at least significantly reduce, about four years of technical debt accumulation, while also adding new capabilities.

Why Move to EdgeX 2.0?

Whether you are an existing EdgeX user or new to the platform and considering adoption, there are several reasons to explore the new EdgeX 2.0 Ireland release:

• First, we’ve completely rewritten and improved the microservice APIs.  I’ve provided some more details on the APIs below, but in general, the new APIs allow for protocol independence in communications, better message security, and better tracking of data through the services.  They are also more structured and standardized with regard to API request / response messages.
• EdgeX 2.0 is more efficient and lighter (depending on your use case).  For example, Core Data is now entirely optional.
• EdgeX 2.0 is more reliable and supports better quality of service (depending on your setup and configuration).  For example, you can use a message bus to shuffle data from the sensor collecting Device Services to exporting Application Services.  This will reduce your reliance on the REST protocol and allow you to use a message broker with QoS levels elevated when needed.
• EdgeX 2.0 has eliminated a lot of technical debt and includes many bug fixes.  As an example, EdgeX micro service ports are now within the Internet Assigned Numbers Authority (IANA) dynamic/private port range so as not to conflict with well-known system or registered ports.

Introducing the V2 APIs

During one of our semi-annual planning meetings back in 2019, the community agreed that we needed to address some challenges in the way that EdgeX microservices communicated – both with each other and with third- party systems.  We identified some technical debt and knew that it had to be addressed in order to provide the platform the base from which new features, better security, and additional means of communications could be supported in the future.  This meant changing the entire API set for all EdgeX microservices.

What was “wrong” with the old V1 APIs?  Here were some of the issues:

• Intertwined data model/object information with poor URI paths that exposed internal implementation details and made the APIs difficult to use.  Here is an example comparing the v1 and v2 calls to update a device.

V1: PUT /device/name/{name}/lastconnected/{time}

V2:  PATCH /device [with JSON body to specify the device info]

• In many cases, requests often lacked any formal response object.  The HTTP status code was all that was returned.
• The APIs and model objects were REST specific and didn’t support other communication protocols (such as message bus communications via MQTT or the like).
• Used a model that was very heavy – often containing full embedded model objects instead of model object references.  For example, in v1, when requesting device information, the device profile and Device Service were also returned.
• Used inconsistent naming and included unnecessary elements.  This made it hard for users to figure out how to call on the APIs without checking the documentation.  
• Lacked a defined header that could be used to provide security credentials/tokens in the future.

Changing the entire API set of a platform is a monumental task.  One that required the collective community to get behind and support.  Given the size of the task, the community decided to spread the work over a couple of release cycles.  We began the work on the new APIs (which we called the V2 APIs) last spring while working on the Hanoi release and completed the work with this release.

The new APIs come with common sense request and response objects.  These objects share new features such as a correlation ID which allows requests and responses among services to be associated, and it also allows the flow of data through the system to be tracked more easily.  When a piece of sensor data is collected by a Device Service, the correlation ID on that data is the same all the way through the export of that data to the north side systems.  Below is a simple example of the new request and responses – in this case to add a new Device Service.

 

Importantly, the V2 APIs set us up for new features in the future while also making EdgeX easier to interact with.

EdgeX 2.0 Feature Highlights

Technical debt removal and the new V2 APIs aside, what else was added in EdgeX 2.0?  Plenty!  Here is a sample of some of the more significant features.

Message Bus and Optional Core Data

In EdgeX 1.0, all communications from the Device Services (the services that communicate with and collect data from “things”) and Core Data was by REST.  In EdgeX 2.0, this communication can be performed via message bus (using either Redis Pub/Sub or MQTT implementations).  In addition to more “fire and forget” communications, the underlying message bus brokers used in message bus communications offer guarantees of delivery of the message.

Moreover, EdgeX 2.0 takes the message bus implementation a step further by allowing Device Services to send the data directly to Application Services via message bus.  Core data becomes an optional secondary subscriber in this instance.  For organizations that do not need to persist sensor data at the edge, this option allows the entire Core Data service to be removed from deployment helping to lighten EdgeX’s footprint and resource needs.

REST communications from Device Services to Core Data can still be done, but it is not the default implementation in EdgeX 2.0.  The diagrams below depict the old versus new message bus service communications.

Improved security

In the 2020 IoT developer survey, security remained one of the top 3 concerns of people building and fielding IoT/edge solutions.  It also remains a prime concern of the members of our community.  The EdgeX project, with each release, has worked to improve the security of the platform.  In this release, there were several additions.

• We created a module and a pattern that provides a common means for all the services to retrieve secrets from the secret store (EdgeX uses Vault as the secret store by default).  We call this feature “secret provider for all.”
• EdgeX uses Consul for service registry and configuration.  In this release, the API Gateway is used to allow access to Consul’s APIs.  Access to the Consul APIs in EdgeX 1.0 was denied making changes in Consul difficult.
• Consul is now bootstrapped and started with its access control list system enabled – offering better authentication/authorization of the service and better protection of the key/value configuration it stores.
• Fewer processes and services are required to run as root in Docker containers.
• The API Gateway (Kong) setup has been improved and simplified.
• EdgeX now prevents Redis, the persistent store for EdgeX, from running in insecure mode.

Simplified Device Profiles

Device profiles are the way that users define the characteristics about sensors/devices connected to EdgeX – that is the data they provide, and how to command them.  For example, a device profile for BACnet thermostats provides information on data a BACnet thermostat sends, such as current temperature and humidity level. It also defines which types of commands or actions EdgeX can send to the BACnet thermostat such as the ability to set the cooling or heating point.  

Device profiles are specified in YAML or JSON and uploaded to EdgeX.  As such, they are the critical descriptions that makes EdgeX work.  Device profiles allow users to describe their sensors and devices to EdgeX without having to write lots of programming code. 

Writing device profiles in previous releases could be long and tedious depending on the device and what type of data it provided.  We greatly simplified and shortened device profiles in EdgeX 2.0.  As an example, here is the same essential profile in EdgeX 1 and EdgeX 2.

New Device Services

The growth of an open-source community can often be measured by how well it is attracting new contributors into the project.  During this release, thanks to some new contributors, we added several new Device Services.  Here is the new Device Services you can now find in the project:

• Constrained Application Protocol (CoAP) is a web transfer protocol used in resource constrained nodes and networks.
• GPIO (or general pin input/output) is a standard interface used to connect microcontrollers to other electronic devices.  It is also very popular with Raspberry Pi adopters given its availability on the devices.
• Low Level Reader Protocol (LLRP) is a standardized network interface to many RFID readers.
• Universal Asynchronous Receiver/Transmitter (UART) is serial data communications and is used in modems and can be used with USB in a USB to UART bridge.

These Device Services were contributed to EdgeX 1, but are being updated this summer to EdgeX 2.0.

New Graphical User Interface

In this release, a new and complete interface using Angular.JS (with some Go code for backend needs) has been added.  This GUI, complete with EdgeX branding, aligns with industry standards and technologies for user interfaces and should provide a platform for future GUI needs.

In addition to providing the ability to work with and call on EdgeX services, it provides a GUI “wizard” to help provision a new device (with associated Device Service and device profile).  What would typically take a user several complex REST API calls can now be done with a wizard interface that carefully walks the user through the creation process providing simple fill-in forms (with context help) to create the device.

The GUI also provides a visual status display that allows users to track the memory and CPU usage of the EdgeX services.  In the future, additional visualization will be added to be able to display sensor data.

Application Services

Application Services are used to export EdgeX data off the edge to enterprise and cloud systems and applications.  Application Services filter, prepare and transform the sensor data for easy consumption.  Several additions were made to the Application Services and the SDK that helps create them (called the application functions SDK).  The following is a list of some of the new features and functions:

• New functions to filter sensor readings by device profile name and device resource name before exporting
• Allowing multiple HTTP endpoints to be specified for export by one Application Service
• Subscription to multiple message bus (enabling multiple filters by subscriptions)
• Provided a new template for easier/faster creation of custom Application Services

Additionally, a new LLRP inventory Application Service was contributed to help correlate data coming from RFID readers to backend inventory systems.

EdgeX Ready

EdgeX Ready is a program designed to highlight member organizations that demonstrate the ability to work with EdgeX.  The EdgeX Ready program was launched with the EdgeX 2.0 release in order to promote awareness of users and their organizations that have EdgeX expertise.  This is the first step or a precursor to potentially exploring an EdgeX certification program.

Today, the EdgeX Ready self-assessment process requires an EdgeX adopter to:

• Get and run an instance of EdgeX (and associated services)
• Create and validate a device profile.
• Use the profile with an EdgeX Device Service to provision a device and send sensor data into EdgeX.

When an organization  completes the EdgeX Ready process, they signal to other community members that they have successfully demonstrated they have EdgeX knowledge and experience.  In return, the EdgeX community highlights EdgeX Ready members on the EdgeX Foundry website with an EdgeX Ready badge (shown below) next to their logo.

Additionally, the program hopes to promote sharing of EdgeX device connectivity elements and sample data sets, which are central to the current submission process and helpful to others learning EdgeX.  Future EdgeX Ready programs may highlight additional levels of ability and experience. 

Under the Hood and Behind the Scenes

Effort by DevOps, Testing, Quality Control and Outreach teams often go unnoticed in any software effort.  These teams are composed of unsung heroes of the EdgeX 2.0 as they contributed substantially to this massive undertaking.  In addition to their normal roles of building, testing and marketing EdgeX, they managed to further the project in many ways.

Our DevOps team cleaned up the EdgeX Docker image names (removing unnecessary image prefix/suffix names) and provided descriptions and appropriate tags on all of our images in Docker Hub – helping adopters more quickly and easily find the EdgeX Docker images they need.  They also added informative badges to our GitHub repositories to help community developers and adopters understand the disposition and quality of the code in the repositories.

Our Test/QA team added new integration tests, performance tests and “smoke” tests to give the project an early indicator when there is an issue with a new version of a 3rd party library or component such as Consul – allowing the community to address incompatibilities or issues more quickly.

Finally, our marketing team revamped and upgraded our www.edgexfoundry.org website and create a Chinese version of our website in support of our ever growing Chinese community of adopters.  The welcome mat of our project now has a clean new look, better organization, and a lot more information to provide existing and potential adopters.  The website should help EdgeX adopters the information and artifacts they need more quickly and easily, while also highlighting the accomplishements of the community and its membership.

If all this wasn’t enough, here is a list of some of the other accomplishments the project achieved during this release cycle:

• Improved the Device Service contribution review process.
• Incorporated use of conventional commits in the code contribution process.
• Started a program to vet 3rd party dependencies; insuring 3rd party dependencies are of sufficient license, quality and development activity to support our project.
• Help launch the Open Retail Reference Architecture project to foster the development of an LF Edge reference architecture for retail adopters.
• Entered into liaison agreements with the Digital Twin Consortium and AgStack (a new LF project) to figure out how EdgeX can be better integrated into digital twin systems and help facilitate solutions in the agricultural ecosystem.

More on Ireland

Find more information about the release at these locations.

• Documentation:  https://docs.edgexfoundry.org/2.0/
• Get it via Docker Compose:  https://github.com/edgexfoundry/edgex-compose/tree/ireland
• Wiki: https://wiki.edgexfoundry.org/display/FA/Ireland

On to Jakarta

As always, I want to take this opportunity to thank the wonderful EdgeX team and community.  EdgeX exists because of the incredibly smart and dedicated group of people in the community.  I also want to thank all the fine people at the Linux Foundation.  This release was especially long and difficult, but this team was up to the challenge and they are providing you another great release.  I am proud of their work and privileged to be the chairman of this group.

But our work is not done.  The EdgeX community has already held its planning session for our next release – codenamed Jakarta – that will release around November of 2021.  Look for more details on our planning meeting and the Jakarta release in another blog post I’ll have out soon.

Enjoy the summer, stay safe and healthy (let’s get this pandemic behind us), and please give EdgeX 2.0 a try.

By Melvin Sun (Sr. marketing manager in Intel IoT Group, EdgeX TSC member, co-founder & maintainer of EdgeX China Project) and Kenzie Lan (Operations specialist of EdgeX China community)

EdgeX Foundry, a project under the LF Edge umbrella, is a vendor-neutral open source project on edge computing. 

To support the growing community of EdgeX Chinese developers and ecosystem partners, the project established the EdgeX China project in Q4’19 to drive collaboration in the region.  Since then,  the project community in China has set up local meetups, working groups, and events. In addition, local and language-specific developer and social media channels were created to generate awareness about the project and improve the adoption and experience of Chinese users and developers. 

As of today, the EdgeX China community has gained more than 300,000 followers on mainstream developer platforms of CSDN and OSChina, as well as six WeChat groups! In addition to developers, users and ecosystem partners, there are  ~10 commercial offerings from China based on EdgeX. 

To further support the EdgeX China community growth, the project officially launched its Chinese website (https://cn.edgexfoundry.org/) on June 30th, 2021 to provide awareness of EdgeX Foundry for new developers and users and to keep the local community up to date on events and news. 

The EdgeX Foundry Chinese site is divided into “Home Page”, “Why EdgeX”, “Getting Started”, “Software”, “Ecosystem”, “Community”, “Latest”, and “EdgeX Challenge China 2021”. This site provides a systematic introduction to EdgeX’ s architecture, methods of use, services, community, latest news, and overview and information on the ongoing 2021 China EdgeX Challenge for EdgeX users to compete for prizes by creating solutions based on EdgeX. Visitors can easily jump from the English website (https://www.edgexfoundry.org/)to the Chinese through the link between them.

CTOs, architects, developers, students, and business folks all are welcome to learn and exchange practical experience in the EdgeX China community. The EdgeX community will continue to grow and improve in collaboration with members around the world.

Thanks to all involved in creating and maintaining this China-focused version of the EdgeX Foundry website!

This post originally published on the AgStack website

The newest Linux Foundation project, AgStack, announces a liaison with LF Edge and EdgeX Foundry to dock existing EdgeX software for IoT into AgStack’s IoT Extension. AgStack has also agreed to participate in the EdgeX Foundry Vertical Solutions Working Group to explore the adoption and use of the EdgeX IoT/edge platform as an extension to its design of digital infrastructure for agriculture stakeholders.  Through mutual LF project cooperation, the two projects hope to create a complete edge-to-enterprise open-source solution as part of AgStack that can help the global agricultural ecosystem.

The goals of the cooperation between the two projects are to:

• Utilize the existing EdgeX Foundry framework to quickly accelerate AgStack’s reach into the agriculture edge – providing a universal platform for communicating with the ag industry’s sensors, devices and gateways.
• Extend the EdgeX framework to handle agricultural edge use cases and unique ag ecosystem protocols, models, data formats, etc.
• Jointly work on edge-to-enterprise market ready solutions that can be easily demonstrated and used as the foundation for real world products benefiting ag industry creators and consumers.
• Setup an exchange (as fellow LF projects) to mutually assist and share lessons learned in areas such as project governance, devops, software testing, security, etc.

“We are in the early stages of defining and building the AgStack platform and we prefer not to have to start from scratch or reinvent the wheel as we build our industry leading open-source platform” said Sumer Johal, Executive Director of AgStack.  “EdgeX Foundry gives us the opportunity to leapfrog our IoT / edge efforts by several years and take advantage of the ecosystem, edge expertise, and lessons learned that EdgeX has acquired in the IoT space.”

“As a versatile and horizontal IoT/edge platform, we are excited to partner with AgStack who can help to highlight how EdgeX can be used in  agriculture IoT use cases and how the AgStack and EdgeX communities can collaborate to scale digital transformation for the agriculture and food industries” said Jim White, Technical Steering Committee Chairman of EdgeX Foundry.  “Even though a fellow LF project, we view AgStack as one of our vertical customers – applying EdgeX to solve real world problems – and what better place to demonstrate that than in an industry that feeds the world.”

 About AgStack

  AgStack was launched by the Linux Foundation in May 2021.  AgStack seeks to improve global agriculture efficiency through the creation, maintenance and enhancement of free, re-usable, open and specialized digital infrastructure for data and applications.  Founding members of AgStack include Hewlett Packard Enterprise, Our Sci, bscompany, axilab, Digital Green, Farm Foundation, Open Team, NIAB and Product Marketing Association.  To learn more visit https://agstack.org.

 

In four short years, EdgeX has become the global standard at the IOT Edge; this blog examines why and looks to the future.

By Keith Steele, CEO IOTech, and member of LF Edge Board and EdgeX Technical Steering Group.

The emergence of Edge Computing

Back in 2017, “edge computing” was a forecast in a Gartner report, it was called “the mother of all infrastructures.” A new computing model, edge computing promised to alter how businesses interact with the physical world.

With edge computing, data from physical devices—whether it be a drone, sensor, robot, HVAC unit, autonomous car, or other intelligent device—is acquired, processed, analyzed, and acted upon by dedicated edge computing platforms. The processed data can be acted upon locally and then sent to the cloud as required for further action and analysis.

Edge computing helps businesses very rapidly and inexpensively store, process, and analyze portions of their data closer to where it is needed, reducing security risks and reaction times, and making it an important complement to cloud computing. It is, however, a complex problem.

As more devices generate more data, existing infrastructure, bandwidth restrictions, and organizational roadblocks can stand in the way of extracting beneficial insights. What is more, there is no one-size solution that fits everyone. Different applications require different types of compute and connectivity and need to meet a variety of compliance and technology standards.

EdgeX – A Strategic Imperative

This inherent complexity at the edge was recognized as a major barrier to market take- up at the edge; in the same way that common standards and platforms are applied across most of the IT stack, there was recognition that a common ‘horizontal’ software foundation at the edge was needed.

In June 2017, in Boston MA, under the auspices of the Linux Foundation, around 60 people from many technology companies, gathered from around the World, to constitute the EdgeX Foundry open-source project;  the attendees had one aim: To create EdgeX Foundry as the global open edge software platform standard!

.       

At the outset, the EdgeX team saw an open edge software platform as a strategic imperative.  EdgeX enables successful edge implementation strategies and makes the IT/OT boundary a key value-add in building new end-to-end IoT systems. Platforms like EdgeX support heterogeneous systems and ‘real time’ performance requirements on both sides of the boundary, promote choice and flexibility, and enable collaboration across multiple vendors.

Four years later with literally millions of downloads, thousands of deployments across multiple vertical markets, and a truly global ecosystem of technology and commercialization partners, we can   justifiably claim to have achieved our goal.

Over the years the project has had something like 200 code contributors, from companies as diverse as Dell, Intel, HP, IOTech, VMWare, Samsung, Beechwoods, Canonical, Cavium Networks, and Jiangxing Intelligence.  Some made small contributions, while others have stayed for the whole journey. This blog is a tribute to all who have contributed to the project’s continued success.

The Importance of Ecosystem

Open-source projects without a global ecosystem of partners to develop, productize, test, and even deploy stand little chance of success.

The EdgeX ecosystem was greatly enhanced in January 2019 when EdgeX, along with project Akraino, became one of two founding projects in LF Edge, which is an umbrella organization created by the Linux Foundation that “aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system.” This project aims to bring together complementary open-source technologies.

EdgeX standalone pre- 2019 was already of great value. However, as a founding project under the umbrella of LF Edge, it proved even more valuable as the momentum increased with additional global collaboration. The additional amplification and support across LF Edge projects, community, and members, helped turn EdgeX into a real high velocity project.

     

\EdgeX Fundamentals

There are several fundamental technical and business tenets we set out to solve with EdgeX:

Leveraging the power of Edge and Cloud Computing

Our starting point is that edge and cloud complement one another.

Cloud computing and data centers offer excellent support for large data storage and computing workloads that do not demand real-time insights. For example, a company may choose cloud computing to offload long-term data processing and analysis, or resource-intensive workloads like AI training.

However, the latency and potential costs of connections between the cloud and edge devices makes cloud computing impractical for some scenarios – particularly those in which enterprises need faster or real-time insights, or the edge produces massive amounts of data that should first be filtered to reduce cloud costs. In these cases, an edge computing strategy offers unique value.

Open vs. Proprietary

The idea behind EdgeX was to maximize choice so users did not have to lock themselves into proprietary technologies that, by design, limit choice.

Given the implicit heterogeneity at the Edge, ‘open’ at a minimum means the Edge X platform had to be silicon, hardware, operating system, analytics engine, software application and cloud agnostic. It would seem odd to embrace IoT diversity at the edge, but then be tied to a single cloud vendor, hardware supplier, application vendor or chip supplier.

Secure, Pluggable and Extensible Software Architecture

To offer choice and flexibility we chose a modern, distributed, microservices based software architecture, which we believe supported the inherent complexities at the edge. The other really big thing we defined was a set of open standard APIs that enable ‘plug and play’ of any software application at the Edge. Coming back to ‘product quality’ we also wanted these maintained in a way that any changes to the APIs did not mean huge rewrites for application providers.

Edge Software Application ‘Plug and Play’

A key promise of EdgeX is that it provides a standard open framework around which an ecosystem can emerge, offering interoperable plug-and-play software applications and value add services providing users with real choice, rather than having to deal with siloed applications, which may potentially require huge systems integration efforts.

EdgeX ensures that any application can be deployed and run on any hardware or operating system, and with any combination of application environments. This enables real flexibility to deliver interoperability between connected devices, applications, and services across a wide range of use cases.

Time-Critical Performance and Scalability

Many of the applications we want to run at the edge, including specialist AI and analytics applications, need access to ‘real-time’ data. These can be very challenging performance constraints, e.g., millisecond or even microsecond response times, often with absolute real-time predictability requirements. Edge systems can also be very large-scale and highly distributed.

The hardware available to run time-critical Edge applications is often highly constrained in terms of memory availability or the need to run at low power. This means edge computing software may need to be highly optimized and have a very small ‘footprint’.

Access to real time data is a fundamental differentiator between the edge and cloud computing worlds. With EdgeX we decided to focus on applications that required round trip response times in the milliseconds rather than microseconds.

Our target operating environments are server and gateway class computers running standard Windows or Linux operating systems. We decided to leave it to the ecosystem to address Time Critical Edge systems, which required ultra-low footprint, microsecond performance and even hard real time predictability. (My company – IOTech- just filled that gap with a product called Edge XRT. Its important real-time requirements are understood in full, as decisions taken can significantly impact success or failure of edge projects.)

Connectivity and Interoperability

A major difference between the edge and cloud is inherent heterogeneity and complexity at the edge. This is best illustrated in relation to connectivity and interoperability requirements, south and northbound:

• Southbound: The edge is where the IT computer meets the OT ‘thing’ and there is a multitude of ‘things’ with which we will want to communicate, using a range of different ‘connectivity’ protocols at or close to real time. Many of these ‘things’ are legacy devices deployed with some old systems (brownfield). EdgeX provides reference implementations of some key protocols north and southbound along with SDK’s to readily allow users to add new protocols where they do not already exist; ensuring acquired data is interoperable despite the differences in device protocols. The commercial ecosystem also provides many additional connectors, making connectivity a configuration versus a programming task
• Northbound: Across industry, we also have multiple cloud and other IT endpoints; therefore, EdgeX provides flexible connectivity to and from these different environments. In fact, many organizations today use multi-cloud approaches to manage risk, take advantage of technology advances, avoid obsolescence, obtain leverage over cloud price increases, and support organizational and supply-chain integration. EdgeX software provides for this choice by being cloud agnostic.

How does the EdgeX Vendor Ecosystem deliver customer solutions?

There are many companies offering value add products and services to the baseline open-source product, including mine, IOTech. There are also may examples of live deployments in vertical markets such as manufacturing and process automation, retail, transportation, smart venues, and cities etc.  See the EdgeX Adopter Series presentations for some examples.

Where Next for EdgeX?

The EdgeX project goes from strength to strength, with huge momentum behind its V1 Release and we will soon release EdgeX 2.0, a major release which includes all new and improved API set (eliminating technical debt that has incurred over 4 years), more message bus communications between services (replacing REST communications where you need more quality of service and asynchronous behavior), enhanced security services, and new device/sensor connectors.  The EdgeX 2.0 release will also emphasize outreach, including much more of a focus on users as well as developers.  With this release, the community launches the EdgeX Ready program.  The program is a means for organizations and individuals to demonstrate their ability to work with EdgeX.

Some Closing Thoughts

The full promise of IoT will be achieved when you combine the power of cloud and edge computing: delivering real value that allows businesses to analyze and act on their data with incredible agility and precision, giving them a critical advantage against their competitors.

The key challenges at the edge related to latency, network bandwidth, reliability, security, and OT heterogeneity cannot be addressed in cloud-only models – the edge needs its own answers.

EdgeX and the LF Edge ecosystem maximize user choice and flexibility and enable effective collaboration across multiple vertical markets at the edge helping to power the next wave of business transformation. Avoid the risk of getting left behind. To learn more, please visit the EdgeX website and LF Edge website and get involved!

 

Written by Aaron Williams, LF Edge Developer Advocate

It’s our favorite time of the year – where we take a step back and reflect on what we have accomplished and honor the members of our community who have gone above and beyond to support EdgeX Foundry.  We are pleased to announce the launch nominations for the 4^th Annual EdgeX Community Awards.

Milestones

Back in 2018 when we started the awards, we had about 1,000 Docker downloads and about 20 contributors.  Today, we are well over 7 million downloads and have 4 times the number of contributors.

In 2020, we expanded into Asia, especially China, which was demonstrated by the amazing turn out at EdgeX Foundry China Day 2020.  We also kicked off the EdgeX Foundry Adopter Series, where the community learns more about how companies around the world use EdgeX.  In addition to two more successful releases, we also announced the creation of the Open Retail Reference Architecture (ORRA) – a project to deliver a base edge foundation to the retail industry – with a presentation from IBM, Intel, and HP.  There were many more events and milestones (like debuting our brand-new website) that we could dive into, but we want to focus in the opening for nominations of the EdgeX Awards!

How to Participate

If you are already a member of the EdgeX Foundry community, please take a moment and visit our EdgeX Awards page and nominate the community member that you feel best exemplified innovation and/or contributed leadership and helped EdgeX Foundry advance and grow over the last year.  Nominations are being accepted through April 7, 2021.

The Awards

Innovation Award:  The Innovation Award recognizes individuals who have contributed the most innovative solution to the project over the past year.

Previous Winners:

2018- Drasko Draskovic (Mainflux) and Tony Espy (Canonical)

2019- Trevor Conn (Dell) and Cloud Tsai (IOTech)

2020- Michael Estrin (Dell Technologies and James Gregg (Intel)

Contribution Award:  The Contribution Award recognizes individuals who have contributed leadership and helped EdgeX Foundry advance and continue momentum in the past year. This includes individuals who have led work groups, special projects, and/or contributed large amounts of code, bug fixes, marketing material, documentation, or otherwise significantly advanced the efforts of EdgeX with their drive and leadership.

Previous Winners:

2018- Andy Foster (IOTech) and Drasko Draskovic (Mainflux)

2019- Michael Johanson (Intel) and Lenny Goodell (Intel)

2020- Bryon Nevis (Intel) and Lisa Ranjbar (Intel)

To learn more about EdgeX Foundry, visit our website or join our Slack to ask questions and engage with community members. If you are not already a member of our community, it is really easy to join, simply visit our wiki page and/or check out our Git Hub.  And you can follow us on Twitter, and LinkedIn.

 

Written by James Butcher, EdgeX Foundry QA&Test Working Group Chair and Edge Xpert Product Manager at IOTech Systems

 

Edge computing is all about the premise of an organization processing its operational data at the edge of the network. That means performing data collection functions and running decision making and control algorithms as close to the edge sensors and OT devices as possible.

The EdgeX Foundry framework helps makes that premise a reality and provides an open, vendor-neutral approach for doing so. However, we must never lose sight of the fact that businesses will want to understand the full implications, including the fully loaded cost, of rolling out an edge system.

The EdgeX QA & Test Working Group

The EdgeX QA & Test working group is responsible for ensuring that releases meet the high standards of reliability and robustness that are required at the Industrial IoT edge. Our remit includes verifying the framework is well tested and ensuring we have the processes in place to maintain and monitor these high standards.

Solid Testing as Standard

EdgeX Foundry is an open source community project under the LF Edge umbrella and we take testing and reliability very seriously. We developed our own EdgeX testing hardness on top of a test framework called TAF. You’ll hear us speak about TAF a lot – it stands for Test Automation Framework and supports the functional, integration and performance testing needs that we have across the project. A version of EdgeX is only released when the TAF reports all tests are passing, for example.

EdgeX is transitioning to a second version of its APIs so there has been a big emphasis on ensuring the V2 API is accurately tested. TAF has been invaluable here because we have been able to easily update and add new tests for the new API. We are pushing ahead for the first release of the new APIs in the EdgeX Ireland release due in the spring.

Gathering Performance Metrics

The QA & Test group also record and gather performance metrics associated with the usage of the EdgeX platform. A common question from users is what sort of hardware is EdgeX aimed at and how fast can it perform? Well, of course, EdgeX has been designed to be hardware and operating system independent, but key metrics like footprint, CPU usage and latency of data flow do need to be provided so users can plan which IoT edge gateways and edge servers to use. Sometimes users have the luxury of being able to select brand new hardware to deploy in their edge projects, but often it is necessary to re-use existing already-deployed hardware.

Over the last release cycle, culminating in the EdgeX Hanoi release, the QA & Test group have put renewed focus on gathering and reporting these performance metrics. We have also improved the accuracy of the figures by increasing the number of tests ran and stating metric averages along with minimum and maximum readings, etc. Note that TAF can also monitor performance regressions. We’ve added threshold testing such that failures are reported if a code commit adversely affects any of the performance metrics. These are all tools to ensure that EdgeX quality and performance remains as high as possible as the project evolves.

Presenting the Performance

We’ve decided to go beyond just providing the raw metrics and instead have created a report that presents the key numbers along with some comment and explanation. Please find the Hanoi Performance Report here.

I hope you find this information useful. We are aiming to provide an updated version of this document for each EdgeX release and will track the progression as we go.

Commercial Support is Key

EdgeX is a fantastic project for helping to simplify the challenges of edge computing. The open-source and collaborative nature of the project brings together ideas from edge experts around the world. However, to pick up the point about businesses needing to understand the full implications of selecting an edge solution, companies are usually reluctant to deploy open source code without having guaranteed help at hand and support contracts in place.

So, switching to my other role in the EdgeX ecosystem for moment, let me mention how companies like IOTech provide products and services to mitigate that risk…

I am product manager of Edge Xpert which is IOTech’s value-add and commercially supported implementation of EdgeX. Our Edge Xpert 1.8 release is based on Hanoi and adds another level of features and services to help you. Head over to our website to read about how Edge Xpert can get your EdgeX systems to market much quicker and with less risk.

Future Plans

Obviously quality and robustness is very important to me in both my EdgeX and IOTech roles. Testing is never finished of course, and we are always looking to add to our test and performance tracking capability. Future iterations of the performance testing will include additions for the security services, scalability metrics and performance associated with the EdgeX Device Services – for example, how fast can Modbus data be collected, and how many data points can be received in a certain period, etc. These factors are all important in understanding how the platform will scale as it is deployed and understanding the number of deployments – and thus gateways and edge servers that will be needed.

Open Discussions

Feel free the join the weekly EdgeX QA & Test calls where we discuss progress and issues that need to be addressed. We meet every Tuesday at 8am PST. You can find the meeting links on our page here. To learn more about EdgeX Foundry’s Hanoi Release, click here.