...
Release Themes & Objectives
- Stabilize the original seed code for the EdgeX platform
- Establish dev ops practices, build environment and versioning
- Build community understanding of the platform and code base
- General majority agreement on the architecture
- General majority agreement on micro services and APIsGeneral majority agreement on the development of an open, platform independent, technology agnostic platform for the IoT/edge
- General agreement on longer-term performance targets and technology choices
- Progress towards the definition of unified APIs for security and system management
...
- Supported OS
- Windows 10 (latest 2016 version)
- Linux, Ubuntu 16.04 classic (but does not enforce secure boot)
- EdgeX supports and welcomes other OS providers to test and validate EdgeX works on their OS
- Example, Canonical plans to test/validate EdgeX on Ubuntu Core 16
- Supported Hardware:
- Intel x86
- EdgeX welcomes and will support 3rd party contribution of Arm support. Stretch goal: Arm Note: work to port to Arm is nearing completion although the automated build environment needs further attention.
- Performance targets stand, but may not be achieved in this release
- EdgeX to develop performance tests to show current performance metrics
- No significant performance-specific work will be accomplished in this release (unless it is easy to achieve with no other impacts)EdgeX will
- provide Provide early Go performance numbers to show intended path to achieve performance targets (that is slowly replacing Java-based micro services with Go or other faster/smaller programming language micro services over the next few releases)performance estimations for alternative Go Lang implementation of microservices
- EdgeX will use current scalability metrics on devices, collection, etc. as scale guidance
- More formal scalability concerns to be addressed in future releases
- All Micro Services microservices hardened; meaning
- Works properly for the intended use case
- It may not be 100% complete implementations for all use cases or parts of a protocol for example, but it provides enough implementation to sustain the demo use cases for Barcelona and could support extension to the full needs or protocol in the future
- Handles errors and exceptions gracefully
- Contains proper unit and integration tests
- Follows good coding standards, and is well documented
- Following some prescribed standard (like Oracle, Google or Twitter guides for Java)
- Performs within the target measures established for Barcelona
- Code base is not exploitable
- API set is solid
...
- Harden as defined above
- Fix known bugs (logging OOM, …)
- Remove/clean up unfinished features (Device Manager)
- Stretch Goal: complete Dell created core services in Go (at least enough to provide performance plan/story)Complete at least one full replacement Core Service in Go Lang to feed estimates on performance trajectory
Device Service SDK and Device Services Tasks and Notes
- Harden as defined above
- Set Provide set of reference Device Services (Modbus, BACnet, BLE, MQTT, SNMP, Fishertechnik, and virtual device)
- Clean up SDK (and Device Services)
- Improve documentation
- Be more developer friendly (see improve tooling - stretch)
- Merge device-sdk into SDK tools
- Cleanup scheduler
- Apply cleanup back to DS (with exception of BACnet and BLE)
- Stretch Goals
- Improve tooling (Eclipse Plugin)
...
- No implementation provided with this release
- Build the longer term roadmap – the EdgeX security story
- Agree on what application-level security features are going to be in EdgeX and what’s going to be provided by the platform that EdgeX runs on (example: the underlying platform must have a keystore)
- Agree on overall security requirements
- Define what EdgeX security service(s) need to be eventually implemented
- Define what security hooks need to be added to the existing micro servicesmicroservices (e.g. APIs)
- Define what standards, protocols, etc. are going to be adhered to and followed by EdgeX (ex: IIC specs, OAuth tokens, etc.)
- Provide guidance on how security features can/should be tested
...