Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The EdgeX Technical Steering Committee (TSC) has established a bi-annual release roadmap to provide a product-quality open source foundation for interoperable commercial differentiation with increasing enablement of real-time fog computing use cases.  In order to provide EdgeX consumers with a predictable foundation to base their commercial offerings on it is the goal of the TSC to outline key release themes at least 12 months in advance and to plan features to be delivered in a given release 6 months in advance.  As with any open source software project, delivery of planned features is based on priority and available developer bandwidth. 

Release cadence (as of January 2018 TSC Face-to-face meeting) is bi-annually, with targets of April and October as release months

Refer to the each page for target functionality by EdgeX release:  

...

'California': ~June 2018

'Delhi': ~December 2018~October 2018

'Edinburgh': ~ April 2019

'Fuji': ~ October 2019

'Geneva': ~ April 2020

We welcome the community to help shape the overall EdgeX roadmap through participation in the working groups and to accelerate delivery of desired functionality by making code contributions to the project. 

...

Below are general notes on overall EdgeX project needs and vision (big and small).  This list will evolve over time and specific features will be slotted into the official roadmap by the TSC (see the individual release roadmap lists).  Initial prioritization will be on enabling commercial offers for Industrial IoT deployments with a stable, product-quality foundation and over time focus will be increased on real-time fog computing use cases.  This list should serve as guiding instructions to contributors at all levels of the project and we welcome experimentation on future needs in addition to contributions to the primary project roadmap.

...

  • Define, integrate, build security infrastructure required of the host platform and utilize in EdgeX Foundry
    • Hardware Enable use of hardware root of trust where available
    • Firewalls
    • Identity/access control stores
    • Key stores 
  • Access Control, Authentication, Authorization, and data protection services (e.g., verification of code integrity and data encryption)
  • Use of blockchain technologies to track / monitor sensor data
  • Encrypt sensitive data at rest
  • Secure inter-service communications (HTTPS)
  • Perform code signing and verification of microservices packages and the Docker Compose manifest
  • Malware scanning
  • Additional hardening
    • Sending logs to external SIEM for monitoring
    • Optionally ensuring that logs are “Tamper Evident/Signed” since the gateway may be deployed in hostile environments
    • Unidirectional access to cloud services
    • Changing default credentials to installation-unique ones
    • Ensure secure-by-default configuration, e.g., use of HTTPS only
    • Whitelisting of devices
    • Monitoring and maintaining security patches for third party components

...

  • Deeper documentation - especially around "Getting Started"
  • Provide example code (Device Services, Export, service replacement, ...)
  • Videos
    • What it does
    • How it works
  • Conference participation and presentation
  • Forum/Blogging and other social media contributions and announcements
  • Meetups
  • Hackathons


Return to TOP


...

Site Navigation: Introduction to EdgeX Foundry | EdgeX Foundry Microservices Architecture | API Reference Definitions  

...