Page tree
Skip to end of metadata
Go to start of metadata

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

EdgeX Foundry is a work in progress.  Participation in and contributions to the project are gladly welcome.  The page contains features, clean up and project direction as viewed by its original creators.  As the EdgeX Foundry community establishes itself, look for more formal project direction to be specified in these pages.


This section is reserved for the EdgeX Foundry project priorities as determined by the project leadership.  It will serve as guiding instructions to contributors at all levels of the project.

Clean Up

The following list constitutes known deficiencies and items for 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

  • Facilitate East-West capability
    • Scale/Load balance across EXF instances
    • EXF Failover
    • Cluster of EXF node management
  • Facilitate North-South capability
    • Gateway (EXF) Device Service
    • Gateway (EXF) to Gateway (EXF) export
  • Plug into system management systems (Pulse, System Center, AirWatch, etc.)
  • Reference implementation device services for common protocols BACnet, Modbus, 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 cloud connectors (Azure, Watson, SAP Hana, etc.)
  • Device Service and Device Service SDK improvements
    • Refactor/simplify the SDK
    • provide more code examples for other protocols (Zigbee, Zwave, ...)
    • Standards (OPC-UA, OCF, etc.)
    • Connectivity to other 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

  • No labels