Delivery: ~June 2018
The main theme for the California release of EdgeX is to provide a solid open source foundation for commercialization and deployment in a wide variety of Industrial IoT edge use cases.
Key to this is the first implementation of priority APIs and reference microservices for security and manageability. Another key theme for the California release is improving overall performance and lowering the baseline footprint of the code base. Work is currently underway for drop-in alternatives for key microservices (e.g. Core Services, Export and Device Services) based in Go Lang with a stretch goal being select implementations in C. Overall, the California release will improve EdgeX ease of use among a larger, more polyglot, development community. Further exploratory work will be done for a high performance message bus as an option to the current REST-based intercommunication between microservices.
Planned features to be delivered we be finalized by the TSC by January 2018 but directional themes are outlined below(as of January 2018 TSC Face-to-Face meeting).
Release Themes and Objectives
- Deliver top priority security and system management APIs and reference implementations of supporting microservices (e.g. key management)
- Deliver on promise for a performant, reliable IoT edge platform
- Reduce overall footprint by an order of magnitude through alternative microservice implementations in Go Lang and possibly C
- Enable near real-time performance (see targets to be finalized in January 2018)Explore future extensions for enabling deterministic real time use casesbelow)
- Improved and overhauled documentation set - moving developer documentation to GitHub
- Device Service SDKs in Go Lang and C/C++
- Blackbox tests for the entire EdgeX API set
- Arm native testing - with continuous integration processes extended to produce artifacts and support the native testing
- 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
- Not MVP, but additional contributions sought for
- Provide additional reference connectivity
- Export Services (e.g. AWS/Greengrass)
- Device Services (e.g. OPC-UA)
- Provide additional reference connectivity
- Device Service and Export Service SDKs in Go Lang
- Stretch goal: C-based Device Service SDK
- Demonstration of EdgeX in real-world POC/test bed, including through possible collaboration with the IIC
General Release Tasks and Notes
- Expand OS support
- Other flavors of Linux
- Mac
- Exploration of implications of RTOS
- Arm
- Provide EdgeX User Interface(s)
...
- Not MVP, but additional contributions sought for
- Alternate (from Docker/Docker Compose) deployment and orchestration options
Micro Service Tasks and Notes
- Meet all performance targetsAddress use of Consul as config/registry?
- Alternative Go-based implementation of Core Services microservices
- More dynamic configuration
- New reference implementations of all micro services in Go Lang (C/C++)
- Implement security & system management API hooks
- Stretch goal: Go-lang based services for select Supporting Services
Application Tasks and Notes
- Implement neccesary hooks for top priority security and manageability functionality
- Define and meet performance metrics
- Provide better scale in terms of number of clients
- Improve the number of messages exported/sec
- Support additional backend integration(s)
- Ex: Watson, AWS/Greengrass, …
- Support additional export feature(s)
- Support additional formats (Ex: Haystack, OPC-UA, …)
- Support additional endpoint types (Ex: DDS, AMQP, …)
- Explore potential use of hyperledger
- Provide additional export capability
- Enrichment services
- How best to facilitate client command requests/actuation
- Not MVP, but additional contributions sought for
- Improved and more dynamic configuration
- Better Export Services flexibility/SDK-like elements
Device Service SDK and Device Service Tasks and Notes
- Provide alternative SDK langauge support in Go Lang and possibly C
- Implement security & system management API hooks
- Not MVP, but additional contributions sought for
- Provide SDK Tool plugins to facility developers
- Ex: Eclipse plugin
- SDK download (non-github oriented)
- Provide new and/or updated Device Services
- Real BACnet or BLE
- Additional DS (i.e. Zigbee, OPC-UA, CANBus, …)
- Reduce/optimize Java DS (remove Spring Framework, etc.)
- Updates to SDK get propagated back out to existing DS via common shared libraries
- 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 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
System Management Tasks and Notes
System management API (action, alerts, metric) as discussed and outlined here
System management Agent
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