...
- 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 utilizing 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.)
- Addiitonal Additional reference connectors for backend appllications 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
...