The release of EdgeX 2.0 has been announced, an open modular platform for enabling interaction between IoT devices, applications, and services. The platform is not tied to specific vendor hardware or operating systems and is being developed by an independent working group under the auspices of the Linux Foundation. The platform's components are written in Go and are distributed under the Apache 2.0 license.
EdgeX allows the creation of gateways that connect existing IoT devices and collect data from various sensors. The gateway organizes interaction with devices and performs initial processing, aggregation, and analysis of information, serving as an intermediary between the network of IoT devices and a local management center or cloud management infrastructure. Processors can also run on the gateways, formatted as microservices. Interaction with IoT devices can be organized over wired or wireless networks using TCP/IP networks and specific (non-IP) protocols.
Gateways of different purposes can be combined into chains; for example, a first-level gateway can handle device management tasks and ensure security, while a second-level gateway (fog server) can store incoming data, perform analytics, and provide services. The system is modular, so the division of functionality into separate nodes is done based on load: in simple cases, one gateway is sufficient, while larger IoT networks may require the deployment of an entire cluster.
At its core, EdgeX is based on the open IoT stack Fuse, which is used in gateways for Dell Edge Gateway IoT devices. The platform can be installed on any hardware, including servers those based on x86 and ARM CPUs, operating on Linux, Windows, or macOS. The project includes a collection of ready-made microservices for data analysis, security, management, and solving various tasks. Programming languages such as Java, JavaScript, Python, Go, and C/C++ can be used to develop custom microservices. An SDK is provided for developing drivers for IoT devices and sensors.
Key Changes:
- A new web interface has been implemented, created using the Angular JS framework. Among the advantages of the new GUI are ease of maintenance and extensibility, the presence of a wizard for connecting new devices, visualization tools, significantly improved interfaces for managing metadata, and capabilities for monitoring service status (memory usage, CPU load, etc.).
- The API for working with microservices has been completely rewritten; it is now independent of the communication protocol, more secure, well-structured (uses JSON), and better tracks the data processed by the service.
- Efficiency has been improved, and the ability to create lightweight configurations has been provided. The Core Data component, responsible for data storage, is no longer mandatory (for example, it can be excluded when there's a need to only process data from sensors without the necessity to store it).
- The reliability has been increased and quality assurance (QoS) tools have been expanded. When transferring data from Device Services (responsible for collecting data from sensors and devices) to Application Services, it is now possible to use a message bus (Redis Pub/Sub, 0MQ, or MQTT), without being tied to the HTTP REST protocol, while managing QoS priorities at the message broker level. Direct data transfer from Device Service to Application Service is also permitted, with optional duplication in the Core Data service. REST protocol data transmission support is retained, but is not used by default.
- A universal module (secret provider) has been implemented for extracting secret data (passwords, keys, etc.) from secure storage solutions such as Vault.
- Consul tools have been engaged for maintaining the registry of services and settings, as well as for managing access and authentication. The API Gateway now supports calls to the Consul API.
- The number of processes and services requiring root privileges in Docker containers has been minimized. Protection against using Redis in insecure mode has been added.
- The configuration of the API Gateway (Kong) has been simplified.
- Device profiles, which specify sensor and device parameters as well as information on collected data, have been simplified. Profiles can be defined in YAML and JSON formats.
- New device services have been added:
- CoAP (written in C) implementing 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) implementing the Low Level Reader Protocol for connecting to RFID tag readers.
- UART (written in Go) with support for UART (Universal Asynchronous Receiver/Transmitter).
- The capabilities of Application Services, which are responsible for preparing and exporting data for subsequent processing in cloud systems and applications, have been expanded. Support for filtering sensor data by device profile name and resource type has been added. It is now possible for one service to send data to multiple recipients and subscribe to multiple message buses. A template for quickly creating custom application services has been proposed.
- The selected port numbers for microservices are aligned with the ranges recommended by the IANA (Internet Assigned Numbers Authority) for private use, which will help avoid conflicts with existing systems.
Source: opennet.ru
