Wydano wersję EdgeX 2.0, otwartej modułowej platformy umożliwiającej interakcję między urządzeniami IoT, aplikacjami i usługami. Platforma nie jest przypisana do sprzętu konkretnego dostawcy ani systemów operacyjnych i jest rozwijana przez niezależną grupę roboczą działającą pod auspicjami Linux Foundation. Komponenty platformy są napisane w języku Go i są dystrybuowane na podstawie licencji Apache 2.0.
EdgeX umożliwia tworzenie bramek, które łączą istniejące urządzenia IoT i zbierają dane z różnych czujników. Brama zajmuje się organizacją interakcji z urządzeniami, a także przeprowadza wstępną obróbkę, agregację i analizę informacji, działając jako pośrednik między siecią urządzeń IoT a lokalnym centrum zarządzania lub chmurą. Na bramach mogą być również uruchamiane przetwarzacze w formie mikrousług. Interakcja z urządzeniami IoT może być organizowana za pomocą sieci przewodowej lub bezprzewodowej z użyciem sieci TCP/IP oraz specyficznych (nie-IP) protokołów.
Bramy o różnych przeznaczeniach mogą być łączone w ciągi, na przykład brama pierwszego poziomu może rozwiązywać zadania związane z zarządzaniem urządzeniami (system management) i zapewnieniem bezpieczeństwa, natomiast brama drugiego poziomu (serwer fog) przechowuje napływające dane, wykonuje analitykę i oferuje usługi. System jest modułowy, więc podział funkcjonalności na poszczególne węzły jest realizowany w zależności od obciążenia: w prostych przypadkach wystarczy jedna brama, natomiast dla dużych sieci IoT może być wdrożony cały klaster.
Podstawą EdgeX jest otwarty stos IoT Fuse, który jest wykorzystywany w bramkach dla urządzeń IoT Dell Edge Gateway. Platforma może być zainstalowana na każdym sprzęcie, w tym serwery na bazie CPU x86 i ARM, działających pod kontrolą Linux, Windows lub macOS. Projekt obejmuje zestaw gotowych mikrousług do analizy danych, zapewnienia bezpieczeństwa, zarządzania i rozwiązywania różnych problemów. Do tworzenia własnych mikrousług można wykorzystać języki Java, Javascript, Python, Go i C/C++. Oferowane jest SDK do opracowywania sterowników dla urządzeń IoT i czujników.
Główne zmiany:
- Zrealizowano nowy interfejs webowy, stworzony przy użyciu frameworka Angular JS. Do zalet nowego GUI należy łatwość w utrzymaniu i rozszerzaniu funkcjonalności, obecność kreatora podłączania nowych urządzeń, narzędzie do wizualizacji danych, znacznie ulepszony interfejs do zarządzania metadanymi oraz możliwości monitorowania stanu usług (zużycie pamięci, obciążenie CPU itp.).
- Całkowicie przerobiono API do pracy z mikrousługami, które teraz nie zależy od protokołu komunikacyjnego, jest bardziej zabezpieczone, dobrze zorganizowane (używa JSON) i lepiej śledzi dane przetwarzane przez usługę.
- Zwiększono efektywność i wprowadzono możliwość tworzenia lekkich konfiguracji. Komponent Core Data, odpowiedzialny za przechowywanie danych, nie jest już obowiązkowy (na przykład można go wykluczyć, gdy konieczne jest jedynie przetworzenie danych z czujników bez potrzeby ich zapisywania).
- Zwiększona niezawodność oraz rozwinięto środki zapewnienia jakości usług (QoS). Podczas przesyłania danych z usług urządzeń (Device Services, odpowiedzialne za zbieranie danych z czujników i urządzeń) do usług przetwarzania i gromadzenia danych (Application Services), można teraz korzystać z szyny wiadomości (Redis Pub/Sub, 0MQ lub MQTT), nie ograniczając się do protokołu HTTP REST i regulując priorytety QoS na poziomie brokera wiadomości. Umożliwiono również bezpośrednie przesyłanie danych z Device Service do Application Service z opcjonalnym duplikowaniem w usłudze Core Data. Wsparcie dla przesyłania danych protokołem REST zostało zachowane, ale nie jest domyślnie używane.
- Zrealizowano uniwersalny moduł (secret provider) do wydobywania tajnych danych (haseł, kluczy itp.) z zabezpieczonych magazynów, takich jak Vault.
- Do prowadzenia rejestru usług i ustawień, a także zarządzania dostępem i uwierzytelnianiem wykorzystano narzędzia Consul. W API Gateway zapewniono wsparcie dla zapytań do API Consul.
- Zminimalizowano liczbę procesów i usług, które potrzebują praw root w kontenerach Docker. Dodano ochronę przed używaniem Redis w trybie niezabezpieczonym.
- Uproszczono konfigurację API Gateway (Kong).
- Uproszczono profile urządzeń, w których określane są parametry czujników i urządzeń oraz informacje o zbieranych danych. Profile mogą być definiowane w formatach YAML i JSON.
- Dodano nowe usługi urządzeń:
- CoAP (napisany w C) z realizacją protokołu Constrained Application Protocol.
- GPIO (napisany w Go) do łączenia z mikrokontrolerami i innymi urządzeniami, w tym płytkami Raspberry Pi, przez porty GPIO (General Pin Input/Output).
- LLRP (napisany w Go) z realizacją protokołu LLRP (Low Level Reader Protocol) do łączenia z czytnikami tagów RFID.
- UART (napisany w Go) z obsługą UART (Universal Asynchronous Receiver/Transmitter).
- Rozszerzono możliwości usług aplikacji (Application Services), odpowiedzialnych za przygotowanie i eksport danych do późniejszego przetwarzania w systemach i aplikacjach chmurowych. Dodano wsparcie dla filtrowania danych z czujników według nazwy profilu urządzenia i typu zasobu. Zrealizowano możliwość wysyłania danych przez jeden serwis do wielu odbiorców oraz subskrypcji na wiele szyn wiadomości. Zaproponowano szablon do szybkiego tworzenia własnych usług aplikacji.
- Wybrane numery portów dla mikrousług są zgodne z zakresami zalecanymi przez IANA (Internet Assigned Numbers Authority) do użytku prywatnego, co pozwoli uniknąć konfliktów z istniejącymi systemami.
Źródło: opennet.ru
