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

Compare with Current View Page History

« Previous Version 4 Next »

This page represents the work backlog for EdgeX.  Items listed on this page are not approved or expected in future EdgeX releases, but have been and continue to be discussed for future releases.  It serves as a "parking lot" for additions, enhancements, and changes/refactoring to be continually reviewed and considered with each release planning session.  The order of items listed is random and should not imply priority.

Feature additions and enhancements

  • ARM 32 support - MongoDB is not available on ARM 32.
  • Full Windows development support - ZeroMQ libraries do not allow (easily) the compiling and development of all of EdgeX on a Windows platform.
  • Alternate (from Docker/Docker Compose & Snappy) deployment and orchestration options for EdgeX.  Today, while the community and users of EdgeX are free to deploy EdgeX as they see fit based on their use case/needs, the EdgeX community provides Docker container images and a docker-compose.yml file to help get and deploy EdgeX.  Going forward, it is anticipated that the community will seek and even need alternate means of deploying, managing, and orchestrating the EdgeX micro services.  Options include using Kubernetes, Swarm, Mesos, Nomad, to name a few.  Additional support may be offered by system management tools or facilities.
  • Changes to configuration in Consul are immediately made available to applications.  However, applications must implement a “watcher” to see a configuration change and then call to get that change (the core-config-watcher in GitHub was meant to demonstrate how to do this but was never implemented or used in any service).  Further, even if micro services are made to be more dynamic in watching for and using new/updated configuration, some of the configuration changes would only work after a restart (ex: the REST endpoint port number of the micro service).  Is there a way to signify which configuration is allowed to be changed at runtime and which can only take affect after a restart of the service.
  • Facilitate command information to be supplied and known to the northern edge systems.  For example, how would we provide Azure IoT with commands that it or a cloud solution could use to actuate on devices?
  • Code signing – how to certify integrity of the system
  • How to secure EdgeX’s devices.  How do we make sure a sensor or device is safe to accept data from?  How do we onboard/provision a device securely?

  • Explore potential use of hyperledger.  How can an audit on data collected at the edge by established and tracked (given the limited resources at the edge)?

  • Replacement edge analytics (replacing Java Drools rule engine with lighter weight reference implementation in alternate language).
    • Allow NodeRed to serve as local analytics engine
  • Protect data at rest (encrypt the database)
  • Protect data in motion (encrypt data passing between services or outside of EdgeX)
  • Support privacy concerns (GDRP, HIP-A, etc.)
  • Improving EdgeX resiliency in face of issues or non-availability of some resources/services/etc.
  • Support truly distributed microservices
    • Allow services to run on multiple host machines
    • Secure distributed EdgeX with reverse proxy 
    • Device from EdgeX instance A triggers action on device on EdgeX instance B
    • Front a collection of duplicate microservices with a load balancer (allow for the microservice copies to scale up or down based on load); allow multiple instances of any microservice (for future load balancing and scaling efforts - today only single instances are allowed)
  • Support additional northbound endpoints
    • AWS
    • IBM Watson
    • IoTivity
    • DDS
    • AMQP
  • Support enrichment functions (an EAI concept) in export services (or application services).  Allow additional data or information to be added to the flow of sensor data to the northbound side.  This might be information about the sensor/device that captured it or information about the commands to actuate back down on a sensor/device.
  • Integrate to edge software/agents
    • AWS Greengrass
    • Microsoft IoT Edge
  • Support additional northbound formats
    • Haystack
  • Support additional southside connectors
    • Profinet/Profibus
    • CANBus
    • LORA
    • IoTivity
    • Zigbee
    • ZWave
  • Better support mesh network protocols (Zigbee, BACNet, etc.) where devices know and sometimes manage other devices
  • Allow for device hierarchy in metadata model:  a device could be a manager for another device while also collecting data itself.  Sending a command to a managing device could mean sending a command to all associated devices.
  • Provide more tooling for the device service SDKs.  The original Java DS SDK was command line driven.  In the future, generating a new SDK can/should be done from tools such as IntelliJ.  
  • Allow EdgeX (the entire platform) to be multi-tenant.  Data and services can be attributed to individual clients and protected from one-another.
  • 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.
  • Revisited and improved security threat model.  Dell did an initial threat model before contributing code to EdgeX.  
  • 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.

    • Should we allow configuration properties be overriden by command line provided properties (like Java allows/provides) for our Go services?
  • Define security testing and implement the necessary harness to automate security testing. 
    • Port scanning (to ensure something hasn't been accidentally left open)
    • Check for weak passwords
    • Test positive and negative access based on access control lists

  • Allow for new category of microservices: “Sharing Services” for East/West data exchange with non-Edgex entities

  • Support binary data.

    • Allow the EdgeX system (from device services through export services) to support binary data such as images, chunks of video or audio via CBOR - as selected by the TSC in summer 2018.  This will require device services, core data, and the export distribution to appropriately handle this type of data.  Local edge analytics may be fed binary data and create intelligence from it to allow for actuation at the edge based on the binary data (example: examine an image an detect the presence of a person of interest).

    • Support alternate message formats for service-to-service exchange (Protobuf, XML, etc.)
  • Wrap any open source software with an API, or provide common / replaceable library to use by services to communicate with the 3rd party infrastructure (Consul, Vault, Kong, MongoDB, database, etc.).  This allows the easier replacement or substitution of the infrastructure in the future.
  • Allow for more messaging between services to support more async, better QoS, and durability of information.  This could be supported by MQTT, AMPQ, 0MQ, DDS, NATS, GRPC, WebSockets, or other alternate technology.  The interfaces to the communications between services should allow for easy replacement.
  • Data visualization - how can sensor data be better visualized and analyzed at the edge?
  • Explore the use of Swagger to document the EdgeX REST API.  EdgeX currently uses RAML to disseminate information on microservice APIs.  Swagger offers more fidelity while also offering better code generation going forward.
  • Add tracing to all services, which will allow better debugging and support
  • Establish a Wiki page to point EdgeX users to extensions, modules, add-ons, etc. offered by the community or 3rd parties, but that are not managed or incorporated by EdgeX Foundry.
  • Many of the original device services where created with driver stacks that are suit for purpose on all platforms, are no longer supported, are not homogeneous in their make up (i.e. having some parts Java while other elements in Python), or are using stacks that are not consider the best option for the protocol today.  The BLE and BACnet device services fall under this categorization.

  • Several of the device services were created to prove, conceptually, how to connect to a device using that protocol, but it may not be a full implementation of the protocol API.  For example, the SNMP device service implements enough to drive a Patlite and a few other devices, but does not understand all of SNMP.

  • Allow services to respond to native init processes (example: as that provided by systemd).  The functionality added with the outlined system management APIs should help facilitate systemd calls

Technical Debt

These are changes to the existing EdgeX microservices or system at-large to address concerns of scalability, flexibility, reliability, maintainability, or otherwise improve the existing system that is otherwise considered inferior design, buggy or otherwise poor quality code.  Technical debt may be thought of simply as "areas of the existing code base we need to fix".

  • Automate generation of API documentation.  The RAML that provides developers with an understanding of the microservice REST calls is maintained by hand.  How can the generation and maintenance of the API documentation be more automated and therefore allow the documentation to be more reflective and consistent with the code base?
  • Device Service SDK improvements (to levels of Java device service SDK)
    • Device discovery & provisioning - allow a device service to provide its own implementation for dynamic and automatic device discover (example - discover any new BLE devices in proximity and automatically provision them in EdgeX)
    • Cache fairly static information (device profiles, device information, etc.)
    • Allow for easier device removal
  • Create simple and complex virtual device services
    • A simple virtual device service should simply push out "readings" as static or random numbers
    • A complex virtual device service should be similar in the database driven approach supported by the current virtual device service in Java.
  • Hide, abstract and/or remove database IDs from EdgeX REST APIs.  Database IDs should not be used to identify anything (devices, services, profiles, etc.) in EdgeX directly.


  • No labels