Delivery:  ~ October 2018

The Delhi release is slated to implement additional features in the security and manageability roadmap, continue to improve overall performance and establish the certification program within the EdgeX project for both commercial instances of the full platform and drop-in "EdgeX-compliant" microservices.  The release will also start to look at EdgeX in a wider context use - with instances spread across a fog deployment.

Key release themes and planned features to be implemented will be detailed after the mid-year TSC Face-to-face meeing (~June 2018).

Release Themes and Objectives

• Implementation of message bus alternative for intercommunication between microservices as an alternative to REST.

  While REST will not go away (a REST API will still exist around each micro service), there may be a need to implement point-to-point messaging between select services or to adopt some type of message bus unilaterally across all of EdgeX to support messaging among services.

  Messaging provides for more asynchronous communications, typically lower latency communications, and better (or more finely tuned) communication quality of service (QoS).  Are there places where messaging might be more appropriate (like between core data and export distro today).  Would a use case dictate the use of an alternate messaging infrastructure be used among all services with an underlying message bus to support it?  Would alternate protocols (SNMP, WebSockets, etc.) be desired in some use cases?  For the Delhi release, some alternate communication requirements, design and early message implementation experimentation is likely to occur.

• Improved performance to continually lower footprint, data collection and actuation latency, lower startup time, etc. which began with the California Release
• Implementation of additional priority features for security and manageability
• Potentially, implementation of specific services and SDKs in C to support deterministic real time use cases (see section below for more details)
• Certification process for EdgeX-compliant microservices to enable a plug-and-play ecosystem 
  
  • Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX)
  • Additional certification processes may be developed around particular cross cutting features such as security.
• Facilitate East/West capability
  • Micro service load balancing, failover, scale-over, ...
  • Device from EdgeX A triggers action on device on EdgeX B
• Address data privacy concerns
  • EU laws and affirmation about data use/storage/etc.
  • HIP-A

General Tasks and Notes

• Certification Process - want to have outlined by Delhi

• Probably will include different levels of certification (micro service, versus “box”, etc.)

• Provide roadmap around technical debt/refactor (what and when)

  • Example:  Device service rewrites (ex: BLE, Bacnet)

• Improving EdgeX resiliency in face of issues or non-availability of some resources/services/etc.

• Potentially, provide EdgeX User Interface(s)

Micro Service Tasks and Notes

• Refresh (to latest releases) and improve north side connectors (like Azure IoT Hub connector)

• Support additional backend integration(s) such as Watson, AWS/Greengrass, …

• Support additional export feature(s)

  • Support additional formats (Ex: Haystack, OPC-UA, …)

  • Support additional endpoint types (Ex:  DDS, AMQP, …)

  • Provide enrichment services

• How best to facilitate client command requests/actuation

• Expose command information north bound (export of actuation information and APIs)

• More dynamic configuration

• Potentially, alternate message infrastructure between some or all the services
  

Device Services and SDK Tasks and Notes

• Provide new and/or updated Device Services
  • Real BACnet or BLE
  • Additional DS (i.e. Zigbee, OPC-UA, CANBus, …)

Security Tasks and Notes

• California release was focused on initially securing the EdgeX “gateway” and remains the priority
  • This work will be extended / augmented in this release (looking at alternative authentication, adding MQTT and other protocol reverse proxy, etc.)
    
• Code signing – how to certify integrity of the system
• The release will start to explore, potentially, securing EdgeX’s devices

• Explore potential use of hyperledger

System Management Tasks and Notes

• California release was focused on an API and System Management API centered on micro service management.  This release will continue that work and expand beyond micro service management.
• Potentially explore "Gateway management" to include:
  
  • Demonstrate basic management of EdgeX via select 3rd party console (ex: VMware Pulse IoT Center, System Center, …)
  • Demonstrate EdgeX software updates
  • Updates to non-EdgeX components (drivers, end-devices)
• Explore alternate deployment/orchestration options (e.g. Kubernetes)

Stretch Goals for the Release

• Facilitate East/West capability
  • Micro service load balancing, failover, scale-over, ...
  • Device from EdgeX A triggers action on device on EdgeX B
• Address data privacy concerns
  • EU laws and affirmation about data use/storage/etc.
  • HIP-A
• Explore streaming analytic needs/implementations
• Address multi-tenancy needs

Items for consideration

These items are suggestion for Delhi or later releases that have not yet been fully vetted or voted on by the TSC, but will be reviewed as part of an upcoming meeting.  Items in this list may be moved to the roadmap for other releases or discarded entirely.

• The EdgeX configuration today is flat - meaning a single layer of key/value pairs with no groups or other structure.  Configuration should, in the future, be categorized and grouped under a sub-structure to simplify the exploration and updating the config.  For example, all properies related to MongoDB connection (host, username, password, etc) would be grouped under a MongoDB configuration structure. 
• Downsampling: It is mentioned that the device service may receive from the device new unattended readings (e.g. in a pub/sub type of scenario). In this case, there should be a setting to specify whether we accept all readings or we decide to downsample because the source is pumping data too fast. This is actually a very common scenario when you deal with high frequency sensor packages.

• Command: in order to protect the device from harmful commands, there should be the possibility to set a Min and Max limit for the value that is accepted on every single command.  in fact the command service today is rather a hollow simple proxy, but in the future we very much envisioned adding additional security, caching to avoid having to hit the DS when unnecessary, and even grouping command requests for better resource conservation (especially for devices like BLE that get woken up when you hit them).

• Data Transformation: This is something we have always considered as a potential in EdgeX – that of a filter, even a small transformation engine between device services and core data. Not a full blown export, but something that serves in a similar fashion and was common across services. We even thought about making it some type of quick CEP/rules engine feeder for those decisions that can’t wait to go through the rest of the layers.