Page History

...

• Not MVP, but additional contributions sought for
  
  • Provide SDK Tool plugins to facility developers
    

    The Java Device Service SDK today is operated by command line execution.  That is, in order to create a new device service, the user must edit configuration settings in a file, then go to the command line and execute an SDK operation, and then finally manually import the new generated project into the tool of choice.  In the future, for the Java SDK as well as other language versions of the SDK, it is preferred to have some sort of plugin (example: Eclipse Plugin) or UI driven tool (“wizard”) to assist developers by providing a more user-friendly facility to capture their configuration options, generate the new device service and load it into to development tool of choice.

    The Device Service SDK today is available through GitHub.  Developers not working on the actual open source products may not be familiar with GitHub and/or may prefer not to have to use Git tools to pull down and work with the SDK.  As an alternative, we could make the SDK (and any necessary elements like libraries) available through a Web site for download.

  • Provide new and/or updated Device Services

    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.

    Many of these devices services need to be updated, made more consistent in makeup and more complete in terms of protocol implementation.

  • Real BACnet or BLE

  Additional DS (i.e. Zigbee, OPC-UA, CANBus, …)

  EdgeX will never provide all the device services necessary to implement every use case and to connect to every type of device or sensor.  However, EdgeX would like to offer reference implementation device services for the most common of IIoT protocols.  EdgeX offers many of those today to include BACNet, Modbus, BLE, and MQTT.  But we need reference implementation device services in OPC-UA, Zigbee, Zwave, CANBus and a others as well.

  • Reduce/optimize Java DS (remove Spring Framework, etc.)

    Updates to SDK get propagated back out to existing DS via common shared libraries

    The Java Device Service SDK is a bit cumbersome/complex to use, tightly coupled in some cases, and hard to maintain or update.  A refactor of the SDK would improve its ease of use, decouple common elements (such as scheduling) from the SDK so that this code does not have to be replicated with each corresponding device service, and improve its overall quality.  The SDK also relies heavily on the Spring Framework which makes it particularly heavy for edge systems.

Security Tasks and Notes

• A OS reverse proxy will be selected and integrated to EdgeX

• Integrate with AAA service (see below)

• With no (or very few) changes to existing micro services at this time

• Currently looking at Traefik for dev/test and possibly NginX for prod

  • This will be for HTTP/S only (meaning security for MQTT and other protocols will not yet be provided)

• An open source Authentication and Authorization server (s). (E.G., Keycloak, Dex, Hydra, …) will be selected and integrated to EdgeX

• Prod deployment models will require integration with centralized AAA.  Initial solution will be to integrate with reverse proxy

• Data Protection Services via HashiCorps’s Vault will be integrated with EdgeX

• This will provide Key Management, Certificate Services, Encryption

• API abstraction to allow 3rd party implementation/extensions

• Some additional research/work needs to be finalized for California around license, external CA support, local crypto library, bootstrap provisioning, local secure store for bootstrap credentials, unattended startup

• Security testing framework

...