Table of Contents
Delivery: ~ October 2018
The Delhi release is slated to implement provide the first system management capabilities while also implementing additional features in the security and manageability roadmap, . Delhi will continue to improve overall performance and show improvements in performance and include tests to monitor and report on potential performance issues. The release will also establish the certification program within the EdgeX project for both commercial instances of the full platform and drop-in "EdgeX-compliant" microservices. The Finally, this release will also start to look at EdgeX in a wider, distributed context use - with instances that is exploring EdgeX instances (or services) spread across a fog deployment.
...
Release Themes and Objectives
- 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 occurDeliver system management APIs in all the microservices and provide a system management agent for orchestrating multi-service system management commands and communications to 3rd party system management tools/platforms. - Go/C replacement services for any remaining Java services.
- Provide new and improved device services in Go and C.
- Notification, Scheduler, Rules Engine replacement services.
- Improved performance to continually lower footprint, data collection and actuation latency, lower startup time, etc. which began with the California Release and offer performance testing to validate performance targets are being met.
- Implementation of additional priority features for security and manageability
- Potentially, implementation of specific services and SDKs in C to support deterministic real time use cases (see section below for more details)
- Certification process for EdgeX-compliant microservices to enable a plug-and-play ecosystem
- Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX)
- Additional certification processes may be developed around particular cross cutting features such as security.
- Arm 32 support and native testing - with continuous integration processes extended to produce artifacts and support the native testing
- Facilitate East/West capability
- Micro service load balancing, failover, scale-over, ...
- Device from EdgeX A triggers action on device on EdgeX B
- Address data privacy concerns
- EU laws and affirmation about data use/storage/etc.
- HIP-A
- Not MVP, but additional contributions sought for
- Provide additional reference connectivity
- Export Services (e.g. AWS/Greengrass)
- Device Services (e.g. OPC-UA)
- Demonstration of EdgeX in real-world POC/test bed, including through possible collaboration with the IIC
- Provide additional reference connectivity
General Tasks and Notes
Certification Process - want to have outlined by Delhi
Probably will include different levels of certification (micro service, versus “box”, etc.)
- ARM 64 support is being provided with the California release. In this release, ARM 32 support is handled.
- CI process that includes cross compiling for Arm 32 platform artifacts
- Micro service Docker container images produced for Arm 32 platforms
- Native platform testing of the micro services on Arm 32 platforms
Provide roadmap around technical debt/refactor (what and when)
Example: Device service rewrites (ex: BLE, Bacnet); allow multiple instances of any microservice (for future load balancing and scaling efforts - today only single instances are allowed)
- Improving EdgeX resiliency in face of issues or non-availability of some resources/services/etc.
Potentially, provide EdgeX User Interface(s)
Micro Service Tasks and Notes
- Meet all performance targets
While more requirements are needed, the overall performance targets for EdgeX are listed at the bottom of this page and include running all the core, support and application micro services in < 1GB or RAM on a 64 bit CPU, requiring less than 32GB of disk storage space, start (collectively) in under 1 minute and actuate from sensor collection to device trigger in < 1 second.In order to accomplish these targets, it is believed the following work must be accomplished for the Delhi release
- Provide 100% compatible and complete Go Lang micro services for the existing Java core, support and application micro services to include core-data, core-metadata, core-command, core-consul (with seed), support-logging, support-notifications, support-scheduler, support-rulesengine, export-client, export-distro.
- Provide device service SDKs and example device services in languages like Go and C/C++
Implement security & system management API hooks
Depending on the implementation needs of security and system management (see below), there may be a need to make changes to the 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. In support of access to services based on access control list security, additional micro service change could be required.
- Refresh (to latest releases) and improve north side connectors (like Azure IoT Hub connector)
Support additional backend integration(s) such as Watson, AWS/Greengrass, …
Support additional export feature(s)
Support additional formats (Ex: Haystack, OPC-UA, …)
Support additional endpoint types (Ex: DDS, AMQP, …)
Provide enrichment services
How best to facilitate client command requests/actuation
Expose command information north bound (export of actuation information and APIs)
More dynamic configuration
Potentially, alternate message infrastructure between some or all the services
Device Services and SDK Tasks and Notes
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
- Real BACnet or BLE
- Additional DS (i.e. Zigbee, OPC-UA, CANBus, …)
...
System Management Tasks and Notes
- California release was focused on an API and System Management API centered on micro service management. This release will continue that work and expand beyond micro service management.
System management API (action, alerts, metric) as discussed and outlined here
System management Agent (see same document above outlining the agent functionality and duties)
- Potentially explore "Gateway management" to include:
- Demonstrate basic management of EdgeX via select 3rd party console (ex: VMware Pulse IoT Center, System Center, …)
- Demonstrate EdgeX software updates
- Updates to non-EdgeX components (drivers, end-devices)
- Explore alternate deployment/orchestration options (e.g. Kubernetes)
Testing/QA
- 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
- 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.
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
Stretch Goals for the Release
...
- The EdgeX configuration today is flat - meaning a single layer of key/value pairs with no groups or other structure. Configuration should, in the future, be categorized and grouped under a sub-structure to simplify the exploration and updating the config. For example, all properies related to MongoDB connection (host, username, password, etc) would be grouped under a MongoDB configuration structure.
- 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.
- 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.