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

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. 

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

'Barcelona': October 2017

'California': ~June 2018

'Delhi': ~December 2018

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. 

Overall EdgeX Foundry Project Vision

Below are general notes on overall EdgeX project needs and vision.  This list will evolve over time and specific features will be slotted into the official roadmap by the TSC.  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.

General Code Clean Up

The following list constitutes known areas for ongoing clean up within the EdgeX Foundry code base.  This is not a bug list, rather a list of more general design flaws, systemic implementation issues, coding practices, etc.

• A base service class is needed for all microservices (the base class could potentially include security and sys management APIs)
• Dynamic configuration change callbacks for all microservices
• Implement Device Manager capability (versus Device)
• Dependency microservice retries and retry policies for service-to-service communications
• More unit, integration, system tests are needed for most microservices
• DevOps (builds, containerization, code reviews, etc.)

Core Platform and Performance 

• Alternative code implementations (e.g. Go Lang, C) to reduce footprint, improve boot times and increase data throughput
  • Goal: deployment of full baseline EdgeX platform in <256 MB memory utilization (ultimate footprint dependent on # of deployed microservices required of use case) 
• Extensions for embedding EdgeX-compliant Device Services on constrained sensors and deploying EdgeX with an RTOS on a constrained controller such as a PLC.  
  • Goal: <10MB with <10ms response times
• Extensions for deploying EdgeX in high-bandwidth streaming analytics use cases
• High-performance messaging bus for intercommunication between microservices on the host device plus between EdgeX and other systems
• Enablement of fog computing use cases
  • Considerations for time-sensitive networking (TSN) and QoS
  • Facilitating East-West capability between EdgeX-enabled nodes
    • Scaling, load balancing, failover, redundacy, etc. across EdgeX instances
    • Clustering of EdgeX node management
  • Facilitating expanded North-South capability
    • Gateway (EdgeX) Device Service
    • Gateway (EdgeX) to Gateway (EdgeX) export
• Additional reference implementations of Device Services for common protocols (OPC-UA, CAN bus, OCF, LoRa, ZigBee, etc.)
• Additional reference connectors for backend applications (AWS, Watson, SAP HANA, etc.)
• Export Services SDK-like facility to allow for
  
  • Additional transformations
  • Additional filtering
  • Alternate encryption and compress routines
  • Address other protocol endpoints (AMPQ, DDS, ...)
• Device Service and Device Service SDK improvements
  • Refactor/simplify the SDK
  • Provide more code examples for other protocols (Zigbee, Zwave, ...)
  • Better-together with standards (OPC-UA, OCF, etc.)
  • Connectivity to other open source IoT platforms/systems (Kura, IoTivity, ...)
  • Alternate language support (C/C++, Python, Go,...)
• Local and remote console user interfaces

Security

• Define, integrate, build security infrastructure required of the host platform and utilize in EdgeX Foundry
  • Hardware root of trust
  • 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

System Management

• Management of EdgeX supporting software
  • Install/uninstall, start/stop & configure databases
  • Install/uninstall, start/stop & configure message brokers/message systems
  • Base service implementation in all microservices
  • Defines interface and API hooks for start, stop, restart, etc. of services
• Microservice Registry Ties to System Management
  • Start Service
  • Stop Service
  • Know service responsive, performance
  • Install/uninstall service
  • Update service (provide rollback in some cases)
• Manage configuration (add, update, delete)
  • Define the port a service runs on
  • Seed service data (example:  Addressable for device services)
  • Notify services of other service state changes
  • Store/understand/manage micro service dependency information (example: point all services to new security service provider)
  • Manage blacklist services (turn off a service for maintenance, etc.)
  • Assist device services provision/remove new devices
  • Discover new devices being connected
• User interface to provide administration
  • Plug into 3rd-party commercial management consoles (VMware Pulse, System Center, etc.)
  • Build "single pane of glass" apparatus for managing of EdgeX across multiple platform instances

Quality Assurance 

• More and improved microservice unit tests
• Checkin/code review procedures
• Test plans/test cases
• Integration tests (service to service)
• Performance testing
• Scalability testing
• Soak testing
• Platform/OS testing
• Release management schedule and procedures
• Automated build, test and release process as part of standard DevOps

Market/Business Needs

• Development of extensions for specific verticals and use cases
• Collaboration with consortium on test beds (IIC, OpenFog, etc.)
• Collaboration with other open source projects (CFF, OCI, CNCF, Kubernetes, etc.)
• Collaboration with SDOs for better together functionality
• Support for multi-tenancy, pay-for-services model built-in (IoTaaS), etc.

Educational Assistance

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

Return to TOP

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

Where to now