Introduced the release of EdgeX 2.0, an open modular platform for interoperability between IoT devices, applications and services. The platform is not tied to specific hardware vendors and operating systems, and is developed by an independent working group under the auspices of the Linux Foundation. The platform components are written in Go and distributed under the Apache 2.0 license.
EdgeX allows you to create gateways that connect existing IoT devices and collect data from various sensors. The gateway is engaged both in organizing interaction with devices and performs primary processing, aggregation and analysis of information, acting as an intermediate link between a network of IoT devices and a local control center or cloud management infrastructure. Gateways can also run handlers designed as microservices. Interaction with IoT devices can be organized over a wired or wireless network using TCP / IP networks and specific (non-IP) protocols.
Gateways for different purposes can be combined into chains, for example, the gateway of the first link can solve the tasks of managing devices (system management) and ensuring security, and the gateway of the second link (fog server) can store incoming data, perform analytics and provide services. The system is modular, so the division of functionality into separate nodes is performed depending on the load: in simple cases, one gateway is enough, and for large IoT networks, a whole cluster can be deployed.
EdgeX is based on the Fuse open IoT stack, which is used in the Dell Edge Gateway for IoT devices. The platform can be installed on any hardware, including x86 and ARM based servers running Linux, Windows or macOS. The project includes a selection of ready-made microservices for data analysis, security, management and solving various problems. To develop your own microservices, Java, Javascript, Python, Go, and C/C++ can be used. An SDK is offered for developing drivers for IoT devices and sensors.
Major changes:
- Implemented a new web interface created using the Angular JS framework. Among the advantages of the new GUI is the ease of maintenance and expansion of functionality, the presence of a wizard for connecting new devices, data visualization tools, a significantly improved interface for managing metadata, and the ability to monitor the status of services (memory consumption, CPU load, etc.).
- Completely rewrote the API for working with microservices, which now does not depend on the communication protocol, is more secure, well structured (uses JSON), and better tracks the data processed by the service.
- Improved efficiency and provided the ability to create lightweight configurations. The Core Data component responsible for saving data is now optional (for example, it can be excluded when you only need to process data from sensors without the need to save).
- Improved reliability and extended the means to ensure the quality of service (QoS). When transferring data from device services (Device Services, responsible for collecting data from sensors and devices) to data processing and accumulation services (Application Services), you can now use the message bus (Redis Pub/Sub, 0MQ or MQTT) without being bound to HTTP - REST protocol and adjusting QoS priorities at the message broker level. Including direct transfer of data from the Device Service to the Application Service with optional duplication to the Core Data service is allowed. Support for data transfer over the REST protocol is retained, but is not used by default.
- Implemented a universal module (secret provider) for extracting secret data (passwords, keys, etc.) from secure storages such as Vault.
- The Consul toolkit is used to maintain a registry of services and settings, as well as to manage access and authentication. API Gateway provides support for calling the Consul API.
- Minimized the number of processes and services that need root privileges in Docker containers. Added protection against using Redis in unsafe mode.
- Simplified configuration of API Gateway (Kong).
- Simplified device profiles, which set the parameters of sensors and devices, as well as information about the data collected. Profiles can be defined in YAML and JSON formats.
- Added new device services:
- CoAP (written in C) with an implementation of the Constrained Application Protocol.
- GPIO (written in Go) for connecting to microcontrollers and other devices, including Raspberry Pi boards, via GPIO (General Pin Input/Output) ports.
- LLRP (written in Go) with an implementation of the LLRP (Low Level Reader Protocol) protocol for connecting to RFID tag readers.
- UART (written in Go) with UART (Universal Asynchronous Receiver/Transmitter) support.
- The capabilities of Application Services, which are responsible for preparing and exporting data for their subsequent processing in cloud systems and applications, have been expanded. Added support for filtering data from sensors by device profile name and resource type. Implemented the ability to send data by one service to multiple recipients and subscribe to multiple message buses. A template is provided for quickly creating your own application services.
- Selectable port numbers for microservices are aligned with the ranges recommended by the IANA (Internet Assigned Numbers Authority) for private use, which will avoid conflicts with existing systems.
Source: opennet.ru