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

The EdgeX Technical Steering Committee has established a bi-annual release roadmap that demonstrates a long-term strategy to provide a product-quality open source foundation for interoperable commercial differentiation.  As with any software project features are implemented based on priority and available bandwidth.  In order to provide EdgeX consumers with a predictable roadmap to base their offerings on it is the goal of the TSC to plan key release themes out at least 12 months in advance and to slot key features to be delivered in a given release 6 months out.

Refer to the each page for target functionality in the first three EdgeX releases.  

'Barcelona': October 2017

'California': ~June 2018

'Delhi': ~December 2018

We welcome the community to help shape the overall roadmap through participation in the working groups and 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 based on priority to enable commercial Industrial IoT deployments with a stable, product-quality foundation and scale over time into new 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 deficiencies and items for ongoing clean up within the EdgeX Foundry code base.  This is not a bug list, but 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.)

Additional Feature Needs

• High-performance messaging bus for intercommunication between microservices
• Facilitate East-West capability between EdgeX-enabled nodes
  • Scaling/load balancing and failover across EdgeX instances
  • Cluster of EdgeX node management
• Facilitate North-South capability
  • Gateway (EdgeX) Device Service
  • Gateway (EdgeX) to Gateway (EdgeX) export
• Plug into 3rd party commercial management consoles (VMware Pulse, System Center, etc.)
• Reference implementation device services for common protocols OPC-UA, CAN bus, OCF, LoRa, ZigBee, etc.
• Local console user interfaces
• Export Services SDK-like facility to allow for
  • Additional transformations
  • Additional filtering
  • Alternate encryption and compress routines
  • Address other protocol endpoints (AMPQ, DDS, ...)
  • Provide additional cloud connectors (Watson, SAP HANA, etc.)
• 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,...)

Quality Assurance Procedures

• 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

Additional Microservice/Subsystem Required

• Security
  • Define, integrate, build security infrastructure for the gateway and utilize in EdgeXFoundry
    • 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
  • EdgeX Supporting Software Management
    • 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
    • Integrate with existing sys mgmt products (Air Watch, System Center, etc.)
    • Build "single pane of glass" apparatus for managing of EdgeX across multiple platform instances

Educational Assistance

• Create 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
• Hackathos

Address Real Time/Near Real Time

• Reduce footprint (image/container size)
• Reduce startup time (~7 mins for all services today depending on RAM/CPU)
• Reduce usage of CPU and RAM
  • Usage of 100% during startup of CPU & RAM
  • Usage of ~6GB during nominal operations
  • Usage of >50% of CPU during nominal operations
• Reduce time from device service collection to rules actuation and/or export
  • ~500ms from collection to actuation today
  • Export service can backlog if collection schedule is below 10s
• Use of better (QoS) and faster inter-service communications like DDS
• Move to RTOS to support the platform for some use cases

Address Additional Business Needs

• Multi-tenancy
• Pay-for-services model built in (IoTaaS)
• EdgeX in consortium test beds (IIC, OpenFog, etc.)

Return to TOP

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

Where to now