EdgeX Foundry was announced in Hanover on April 24th and had its first meeting in Boston on June 1st. The meeting was attended by 50+ people from different geographies and organizations worldwide, ten member companies pledged developer resources, and several working groups were formed. Following is a summary of the excellent progress in the first 100 days.

The vision of EdgeX is to provide a set of microservices for industrial IoT solutions, a rich application framework that is uniformly available on multi-vendor gateways, while allowing for differentiation and value add. These microservices bridge a large set of device protocols and data formats to common REST APIs. It was established under the Linux Foundation (LF) to leverage well-honed structure, processes, and resources that have been tried and refined along the years for developing open source systems. The LF approach involves open communication and complete transparency; for example, code, documents and meeting recordings are available publicly. To insure quality code, EdgeX will only allow well attributed code by certified developers, no anonymous contributions.

Credit: from launch EdgeX slides, April 2017.


EdgeX includes core services for reliably communicating data from connected devices to services. Device services are used to on-board and communicate with devices of different types. Export services are used to communicate the data to applications and to remote services. There is rich meta data capability for applications to be able to query connected devices and their capabilities. Also, a notification and alerting capability for applications to be notified in case of important events, such as when a new device is connected or a sensor value exceeded a threshold. The plan is to add security and system management capabilities, including for secure communication, security patches, and other software updates.

EdgeX is based on the latest software engineering principles and open source methodologies. EdgeX microservices could be implemented in any language, hence it is polyglot; for example, performance critical ones could be implemented in efficient languages such as C or Go, and others implemented in ease of development languages such as Java or Python. These microservices are loosely coupled: could be in the same process, in different processes on the same machine, or on different machines. For example, they might reside on the gateway, on collocated edge servers, or on remote cloud servers. This flexibility is enabled by the REST protocol over HTTP for remote procedure calls (RPCs), which employs URIs for references and JSON for serializing data types.

Furthermore, it is possible to change the implementation of any of these microservices, while the rest of the system continues to work with no modification, since interoperability is based on REST messages. The change could be as big as changing the database engine, or even a change in the implementation language.

For data time series, EdgeX uses more efficient and queue based messaging protocols such as MQTT and ZeroMQ, where the queuing provides for asynchronous communication with the application, to avoid overloading the application with high volume data flows.

Credit: from technical steering committee slides in London meeting, July 2017


To deliver multi-vendor support, which could be multi hardware architecture (x86 vs. ARM) and/or multi OSs (Linux vs. Windows), EdgeX leverages a Git hub based, LF organized, Continuous Integration build system, with provisions for testing, code branching, issue tracking, static/source code analysis, etc. Container technology on Docker Hub is used for code packaging and distribution. Docker Compose is used to install and coordinate multiple Docker microservices, and run the resulting application. Therefore, a developer of one of the EdgeX microservices uploads her source code in a supported language to get processed into a ready to download and execute Docker container for the different target platforms.

Dell Technologies contributed the initial EdgeX code, the culmination of two years of R&D by very capable developers. It is mostly written in Java using Spring, and tested on Windows and different versions of Linux. It has been used at Dell for several months to monitor 12K sensors. It currently has no security or system management support, which are in the process of design by their respective working groups. It includes a device simulator/virtual device and a device SDK for adding support for new device types. In addition, Dell recently released support for the following device types: Modbus, BACnet, Bluetooth-BLE, SNMP, MQTT, Serial (Fischertechnik).

Presently, a community of member companies is evolving the EdgeX code base into the Barcelona release, which targets simple yet practical use cases for multi-vendor PoC demos at the IoT Solutions World Congress in Barcelona on Oct 3rd. The meeting in London on July 19th was to determine the Minimal Viable Product (MVP) for that milestone and finalize its resourcing.


The different ways Pulse IoT Center will work with EdgeX


VMware is a founding member of EdgeX and is actively contributing towards its success. EdgeX provides a highly contrasting approach to Liota for supporting edge devices and for on-boarding connected devices. They both provide for managing these devices through Pulse IoT Center. While EdgeX requires an elaborate build system that includes provisions for the different supported languages, target platforms, and Docker containerization, Liota uses Python, an interpretive language, hence needs none of that. The IoT ecosystem is complex and there will always be cases where Liota’s simple and informal approach will come in handy, in addition to the rich and structured approach of EdgeX. Providing both options to support gateways and connected devices, enriches VMware’s Pulse IoT Center and adds value to its customers.

The following EdgeX working groups are now active:

  1. Technical Steering Committee (TSC): technical authority, forms and oversees the following committees.
  2. Core Services: basic microservices and data model for storage and streaming, meta data and registration.
  3. Device Services: on-boarding devices, sensing and actuation, and both synchronous and asynchronous communication with core services. SDK for implementing new devices.
  4. Applications: exporting facilities and analytics/rules engine support.
  5. Security: all aspects of security end-to-end, including both at rest and in transport.
  6. System Management: devices & servers management and reliable functioning.
  7. DevOps/build process
  8. QE/testing
  9. Requirements and strategy

Following are useful resources:


PS: On Sep 11th 2017 Samsung joined EdgeX as a Platinum member, which makes it the third to join at this highest membership level and grant it a seat at the Board of Directors. In addition to Samsung being an industry leader, this news is significant since Samsung is a manufacturer of IoT gateways, which will now potentially include support for EdgeX. Furthermore, Samsung is interested in both consumer and industrial use cases/customers, which will increase the focus on a more optimized and lighter weight EdgeX with more efficient processing and smaller memory footprint. BTW, as of Sep 13th, the number of EdgeX member companies stands at 61.