...
- Provide alternative SDK language support in Go Lang and possibly C
In addition to lowering the footprint and improving performance of the device service micro services, drawing in more sensors/devices to the EdgeX platform can be achieved by providing more alternative language device service SDKs – primarily those in C/++ and Go.
- 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.
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.)
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.
- Provide SDK Tool plugins to facility developers
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 Kong
This will be for HTTP/S only (meaning security for MQTT and other protocols will not yet be provided)
- Use of JWT for authentication/access token
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
Target Performance
The target is to run all of EdgeX (all the services to include the virtual device service) on a Raspberry Pi 3 (1 GB RAM, 64bit CPU, at least 32GB storage space, running Raspbian Linux distro)
This is not an endorsement of the platform as our favorite or otherwise endorsed platform
It only suggests the general characteristics of a “developer community” target platform
This may not be entirely feasible without all Go replacements, but is the target and the development community will report back when/where this is not possible
For example, it is unlikely the target security implementation will fit on this size platform
Additional “developer community” targets
Startup in 1 minute or less (post OS boot – from micro service start to all services up and available)
Throughput for one piece of data (with one IP device connected by hard wire – versus WiFi) from data ingestion at the Device Service layer, through Core Data, to Rules Engine and back down through Command Service finally to Device Service for actuation will be < 1 second
...