You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The Edinburgh is version 1.0 and a significant milestone in the EdgeX progression.  It was made available shortly after the 2nd anniversary of the project and signaled EdgeX is fit for purpose and ready for wide use/dissemination and long term support in edge/IoT solutions.  The Edinburgh release focuses on an improved user on-boarding experience, support for binary data, better database/persistence abstraction (for future database replacements), testing dashboard and performance testing, the initial implementation of an eventual export service replacement (application services) in addition to additional security and system management needs that were started in 2018.

Version 1.01. was released in mid July 2019 and is a bug fix release to address a few race conditions discovered in v1.0.

Release Themes and Objectives

  • Improved on-boarding for EdgeX users.  This includes documentation, tutorials, dev kits, and other material to make getting, using and understanding EdgeX easier.
  • EdgeX now supports the ingestion, use and export of binary data in CBOR format. Device Services now allow to send binary data as part of the Event/Reading packages. Core and Export Services have been adapted to handle, persist, and route/send binary data as it does integer, float, and string data today. Incorporation of binary data allows custom built local analytics to use the binary data to trigger actuation of devices.
  • EdgeX database-using services (Core Data, Metadata, Export Client, Logging, Notifications, and Scheduling) have been refactored to be more loosely coupled to the persistence mechanism (currently MongoDB). This eases the use of alternative persistent stores and technology (such as streaming) in future implementations and even allow the project to select alternate or additional reference implementation databases in future releases.
  • The Export Services, while functional, create scalability issues. The current EdgeX capability relies on the Export Services to know and understand all possible endpoint distribution mechanisms and transformation capability necessary to support all clients – even if the use case requires only a single, simple client need. As the number and type of EdgeX north side clients expands, this service will be too big and complex to support the north side needs. The initial and simple Application Services in the Edinburgh release have been designed and implemented to support smaller, more tailored exportation needs. These services contain just the functionality (filtering, transformation, enrichment, etc.) needed for a single endpoint. To address multiple endpoints, multiple Application Services will be created. In a way, the Application Services now look more like the south side Device Services – that is functionality dedicated to a particular client protocol and data need. Long term over the course of a number of releases, Application Services will replace EdgeX Export Services as the north side distribution facility.
  • Provide many Device Service implementations using the Delhi release provided Go and C DS SDKs. The Edinburgh release also provides replacement services for the existing Java Modbus, BACNet, MQTT and SNMP device services.

Application Working Group Tasks and Notes

  • The Edinburgh release features a new service type called Application Services as indicated in the major themes and objectives of this release that will be the eventual replacement for Export Services.

Core Working Group Tasks and Notes

  • Per the release themes and objectives above, the services using the database (currently MongoDB) have been refactored to have a better database abstraction architecture and allow for different database persistence in the future.  This includes removing BSON references, hiding domain IDs, providing an abstraction to allow for object identification that is transformed across platforms.  Changes were made to appropriate core, support, and export layer services.
  • Given Go Glide (used for versioning and dependency management) is being deprecated, the project had to move to an alternative.  The Go community is adopting Go modules (formerly vgo) as its replacement.  In this release, the project moved to Go modules for Go code dependency management.
  • Addition of a correlation id that is added to the event/reading created by the device services and used throughout the rest of EdgeX starting with the core services.  A correlation id allows for tracing of a sensor reading across services.  Tracing is the ability to trace a system API request inside and across EdgeX services for the purpose of debugging and performance metrics tracking.  Tracing is provided by frameworks such as GoKit, but EdgeX has not yet adopted such a framework and needs a solution that is language independent (for use across non-Go services like C based Device Services).
  • Scheduler service (and the metadata data) was altered to associate schedule events/schedules to a particular service owner and allow the Scheduler Service to exercise those “owned” by the Scheduler Service on the appropriate service.
  • Edinburgh release also provides the means to start Consul so that the configuration information is preserved and config-seed does not repopulate (or overwrite) the configuration already in Consul.  This allows the setting of configuration by the SMA.

Device Service SDK and Device Services Group Tasks and Notes

  • The additional of several Device Services as stated above.  The list includes Modbus, BACnet, MQTT, SNMP.   As an additional note, all Java Device Services are archived with the Edinburgh release as they no longer function with the changes.
  • The issue of device ownership or management of devices has been corrected in the Edinburgh release.  Metadata is now considered the source of device knowledge for all of EdgeX and with the Edinburgh release, any deleting a device in metadata requires removing all associated metadata information in metadata as well (provision watcher, etc.).
  • To better support their use and to help drive the production of more south-side connectivity, this release includes Device Service SDK tutorials, examples, and how-to guides.
  • The SDKs (and resulting Device Services) have fully integrated the system management APIs into the EdgeX system management capabilities.
  • Improve/simplify the Device Profile – removing unused elements and better naming of elements given recent SDK work.
  • The Addressable, used in multiple areas of EdgeX to identify a service or data destination such as a REST endpoint or MQTT topic, has been relooked and modified to better support the broader needs of project.

Security Group Tasks and Notes

  • Edinburgh includes automated testing of security features (formerly tested manually).
  • With Vault in place to store EdgeX application secrets, the Edinburgh release will include and use Vault namespaces for storing secrets for various services and the release will have some service(s) get/store their secrets in Vault to secure them.  Future releases will require all application secrets (currently stored in configuration) to be stored/obtained via the secure store.
  • EdgeX moved to Kong and Vault latest releases

System Management Group Tasks and Notes

  • In this release, the System Management Agent and associated system management API add the ability to track service CPU usage and metrics.
  • The SMA added an API to provide the health/status check of a service, but this is a proxy to the configuration/registry service.
  • The SMA start/stop/restart capabilities have been refactored to better address Docker environments as well as generic executable calls.

Test/QA/Documentation Group Tasks and Notes

  • With automated blackbox tests in place, the Edinburgh release includes better visualization/dashboard of test results (including look up and display of historical test results).
  • The Edinburgh release includes the capture of resource metrics to monitor performance.
  • Security tests have been automated as mentioned above in the Security Group tasks.
  • For the Edinburgh release, code contributors will now be required to supply additional or updated blackbox tests to cover changes made to the code base with any PR.

DevOps Group Tasks and Notes

  • EdgeX Go code (inclusive of all development, build and test environments) moved to Go 1.11.
  • EdgeX Go code uses modules in place of Glide.
  • EdgeX will updated to Consul 1.2.3 for Edinburgh.

General Tasks and Notes

  • EdgeX has used Rocket Chat as the message channel for contributor and user information exchange since the project’s inception.  The community is switched to Slack during this release – a more widely used and accepted form of developer communications.
  • With the Edinburgh release, the community has resolved to adopt a “Release Manager” to monitor, guide, document and manage each release.
  • EdgeX defined and advertised its support contract/policy (LTS strategy) to the world with the Edinburgh release.
  • No labels