Delivery:  fall 2017

This fall's release is focused on delivering a minimum viable product (MVP).  It ould not be a product ready for mission critical use cases, but it is the hope of the EdgeX community that after the fall release, the shape of the architecture, APIs, etc. are such that the larger IoT development community will feel comfortable exploring and using EdgeX is upcoming IoT projects.

Release Themes & Objectives

• Stabilize the platform
• Build community understanding of the platform
• General majority agreement on the architecture
• General majority agreement on micro services and APIs
• General majority agreement on the development of an open, platform independent, technology agnostic platform for the IoT/edge
• General agreement on temporary performance targets

General Release Tasks and Notes

• 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 Hardeware:
  • Intel
  • EdgeX welcomes and will support 3rd party contribution of Arm support
• 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 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 langauge micro services over the next few releases)
  • 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 will be harden; 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

Application Layer (export services and the rules engine micro service) Tasks and Notes

• Harden as defined above
• Provide Azure IoT Hub integration (improve/clean up the existing Dell work)
• Provide routing to endpoints by device id
• Support MQTTS and HTTPS for endpoint distribution
• No additional formats/transformations/filters/etc. will be provided beyond what already exist in the export services today
• Provide guidance on number of simultaneous clients that can be supported (to address any potential scale problems with the export services)
• Stretch Goal:  binary message format distribution (picking one to start)

Core & Support Services Tasks and Notes

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

Device Service SDK and Device Services Tasks and Notes

• Harden as defined above
• Provide the Dell 7 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)

Security Tasks and Notes

• No implementation provided with this release
• Build the longer term roadmap – the EdgeX security story
• Agree on what 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 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 services
• 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

System Management Tasks and Notes

• No implementation provided with this release
• Agree on requirements
• Agree on what features are going to be in EdgeX and what is reserved for OS, 3rd party systems, other open source systems, etc.
• Define what system management services need to be implemented as part of EdgeX (if any)
• Define what system management hooks need to be implemented
• Define any system management standards that will be followed/used in system management implementations (ex:  LWM2M)
• Stretch goal:  add some simple system manage hooks/capability into BaseService of EdgeX micro services – based on Dell Fuse work (for service start, stop …)

Test/QA Tasks and Notes

• Unit and integration tests for all micro services (all public methods)
• Implement Blackbox testing
  • Select and/or implement black box test framework
  • Testing must occur on all supported MVP platforms
  • Setup performance tests for capturing performance metrics of a micro service or combination of services
• Have check styles in build process
• Setup Bug tracking system

DevOps/Build/CI/Process Tasks and Notes

• WG allowed to setup their processes (Agile, Scrum, etc.) as they see fit (no community wide process for now)
• Automate build of code and docker microservices
• Implement standards on code commenting, branching, versions, …
  • Adopt and apply the Google code standards (aka Style Guides) for all code
• Stretch Goal:  Automate build of API documentation (Javadoc, raml-doc ?)