IoT Azure: Architektura referencyjna
Dziś przyjrzyjmy się bliżej proponowanej przez Microsoft architekturze rozwiązania /applikacji IoT. Wracamy do podziału Things-Insights-Actions.
Informacje, które uzyskujemy z procesu przetwarzania danych warto zapisać. Nie jest to konieczne, możemy mieć bezstanowy system, który od razu podejmie akcje, ale w większości warto zachować informacje do przyszłego użycia.
Informacja informacji nie równa, część informacji warto, aby była dostępna na gorącej ścieżce. Natomiast wszystko inne warto zachować na chłodno jako dane archiwalne. Hot Path to baza danych i Microsoft zaleca tutaj oczywiście Cosmos DB ale chodzi tylko żeby była to dokumentowa baza danych. Natomiast Cold Path to po prostu dyski, miejsce fizycznego przechowywania, czyli Storage Account i raczej bloby. Dane możemy też duplikować od razu np. do cacha.
Prawdopodobnie będziemy potrzebowali też dodatkowych akcji formatowania danych, czyli Azure Functions.
Ścieżka gorąca to informacje ważne które zasługują na w miarę możliwości szybką reakcję, czyli akcję systemu, lub interakcję z użytkownikiem systemu.
Interakcja z użytkownikiem systemu może być zrealizowana na milion sposobów, to w końcu normalny system informatyczny, ale możemy sobie przyjąć, że będzie to jakaś aplikacja webowa, która wyświetli ważny komunikat, pokaże kilka wykresów (wykresy zawsze się dobrze sprzedają na spotkaniach budżetowych) i umożliwi podjęcie manualnych akcji, takich jak choćby przestawienie parametru na urządzeniu sprawiającym kłopot.
Akcja systemu będzie raczej automatyczna np. wyłączenie nawilżacza powietrza, gdy wilgotność wzrośnie powyżej powiedzmy 60%. Tutaj sprawdzą się Azure Functions, Azure Logic Apps, inne rodzaje integracji.
To bardzo podstawowa architektura i może być rozszerzona w każdym miejscu o potrzebne elementy. Serwisy mogą zostać zamienione innymi. Każdy serwis posiada też dodatkowe opcje i oczywiście ograniczenia. To dużo ruchomych elementów.
Poniżej rysunek architektury jednego z przykładowych rozwiązań prezentowanych przez Microsoft czyli Remote Monitoring Solution with Azure IoT
I jeszcze jedna z Build Azure
Things
Oczywiście mamy tutaj urządzenia raczej rozmawiamy o urządzeniach fizycznych, ale jeśli będą to inne rozwiązania to też ich nie wykluczamy. Oprócz urządzeń mamy tutaj silnie powiązany serwis do provisioningu (takie staropolskie słowo) urządzeń. Chodzi o to, że w jakiś sposób musimy identyfikować czy urządzenie, które będzie dalej wysyłać dane do naszego systemu jest urządzeniem dopuszczonym do naszego systemu. Więcej o samym provisioningu będę pisać w dalszych postach, na razie załóżmy, że jest to lista urządzeń na zasadzie nr seryjnych producenta. (na rysunku mamy IoT Device Provisioning Service)Things - Insights
Połączenie urządzeń i naszego systemu odbywa się przez wysoko wydajny element przyjmujący dane, czyli IoT Hub. IoT Hub to gateway do naszego systemu, ale też wyjście z niego bezpośrednio do urządzeń. IoT Hub pozwala zachować dwukierunkową komunikację z urządzeniami, upraszcza proces aktualizacji oprogramowania, również przechowuje listę urządzeń przypisanych do niego wraz z właściwościami (metadata) samych urządzeń.Insights
Skoro odebraliśmy dane to musimy z nich stworzyć informacje. Tutaj mamy wybór różnych komponentów np. Stream Analytics, Apache Spark na Azure Databricks, Azure Time Series i inne. To właśnie w tym momencie decydujemy czy dane które przetwarzamy są znaczące, czy są to alarmy wymagające natychmiastowych akcji, czy ostrzeżenia, czy są to informacje warte tylko archiwizacji lub pomijalne całkowicie. To tutaj bije serce decyzyjne systemu.Informacje, które uzyskujemy z procesu przetwarzania danych warto zapisać. Nie jest to konieczne, możemy mieć bezstanowy system, który od razu podejmie akcje, ale w większości warto zachować informacje do przyszłego użycia.
Informacja informacji nie równa, część informacji warto, aby była dostępna na gorącej ścieżce. Natomiast wszystko inne warto zachować na chłodno jako dane archiwalne. Hot Path to baza danych i Microsoft zaleca tutaj oczywiście Cosmos DB ale chodzi tylko żeby była to dokumentowa baza danych. Natomiast Cold Path to po prostu dyski, miejsce fizycznego przechowywania, czyli Storage Account i raczej bloby. Dane możemy też duplikować od razu np. do cacha.
Prawdopodobnie będziemy potrzebowali też dodatkowych akcji formatowania danych, czyli Azure Functions.
Action
Zacznijmy od chłodnej ścieżki, czyli dużej ilości danych statycznych (zapisanych na dyskach jako pliki), to idealne dane, na podstawie których możemy się uczyć, wyszukiwać wzorce zachowań, przewidywać problemy - czyli Machine Learning.Ścieżka gorąca to informacje ważne które zasługują na w miarę możliwości szybką reakcję, czyli akcję systemu, lub interakcję z użytkownikiem systemu.
Interakcja z użytkownikiem systemu może być zrealizowana na milion sposobów, to w końcu normalny system informatyczny, ale możemy sobie przyjąć, że będzie to jakaś aplikacja webowa, która wyświetli ważny komunikat, pokaże kilka wykresów (wykresy zawsze się dobrze sprzedają na spotkaniach budżetowych) i umożliwi podjęcie manualnych akcji, takich jak choćby przestawienie parametru na urządzeniu sprawiającym kłopot.
Akcja systemu będzie raczej automatyczna np. wyłączenie nawilżacza powietrza, gdy wilgotność wzrośnie powyżej powiedzmy 60%. Tutaj sprawdzą się Azure Functions, Azure Logic Apps, inne rodzaje integracji.
Action - Things
Akcje muszą zostać przekazane do urządzeń. Odbywa się to ponownie przy pomocy IoT HubaTo bardzo podstawowa architektura i może być rozszerzona w każdym miejscu o potrzebne elementy. Serwisy mogą zostać zamienione innymi. Każdy serwis posiada też dodatkowe opcje i oczywiście ograniczenia. To dużo ruchomych elementów.
Poniżej rysunek architektury jednego z przykładowych rozwiązań prezentowanych przez Microsoft czyli Remote Monitoring Solution with Azure IoT
I jeszcze jedna z Build Azure
Komentarze
Prześlij komentarz