Page History

...

• Implement security & system management API hooks

  Depending on the implementation needs of security and system management, there may be a need to make changes to the SDKs and existing micro service code in support of these facets.  It is likely that each micro service will implement some sort of base service to provide data and system management functionality to the system management agent.  As device services are typically created from an SDK, the same boilerplate code for the base service needs to be added to the SDK(s).  Additional changes may be required in support of security needs (like granting access by access control list).

• 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.
• 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.

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

...

• Performance tests on startup time, request/response times on all APIs, latency to actuation from device service collection, through core data, to rules engine, command back to a device service.
  • Performance metric testing will include CPU and memory usage statistics
• Security testing framework
• Improved unit and integration testing across all EdgeX microservices
  • Returning unit test coverage to ~80%
  • Requires some Go code refactoring and decoupling among resources (like the database, logging, etc.)
  • Use of mock objects to isolate functions under test.

...