Azure je skvělé místo pro zpracování dat z IoT a současně IoT Hub funguje jako systém pro napojení, správu, zabezpečení a oboustrannou komunikaci mezi cloudem a IoT zařízeními. Díky Azure IoT Edge ale můžete vzít střípky cloudu a centrálně je poslat do zařízení a provádět lokální zpracování. Co psát váš kód ve formě modulů implementovaných jako Docker kontejnery a centrálně spravovat kde jaký je? A co filtrovat události s Azure Functions nasazenými přímo v zařízení? A co třeba nějaký Machine Learning model pro lokální detekci krizových či zajímavých situací? Nebo snad Stream Analytics pro agregaci či jinou transformaci rovnou v zařízení, ať se šetří přenosové pásmo? A to všechno v třeba v Raspberry nebo rugged počítači? Podívejme se na Azure IoT Edge.
Cloud dokáže IoT aplikacím nabídnout hodně. Máte v zásadě neomezenou výpočetní kapacitu, platformy pro masivní zpracování dat, strojové učení, umělou inteligenci, specializované systémy uložení dat a samozřejmě i business logiku ať už serverless, v kontejnerech nebo platformních službách. Kromě toho dokáže efektivně přijímat zprávy z IoT zařízení a řešit jejich správu, zabezpečení a tak podobně. Pokud pošleme všechno do cloudu máme fantastické možnosti. Někdy ale není ideální provádět veškeré zpracování v cloudu. Proč?
Konektivita a spotřeba, to jsou hlavní důvody. Přenášet všechna měření přesně a bez agregace není problém na WiFi nebo LTE (nicméně pokud budete streamovat 4K video z 1000 zařízení tak to pocítíte i tam), ale často musíte použít technologie s podstatně horším poměrem přenosové kapacity vs. ceny. Proč posílat hodnotu nějakého ukazatele když je plus mínus nula, když to můžem poslat jednou a zbytek filtrovat dokud nedojde k významnému výkyvu? Nebo obrazová data - máme posílat snímky do cloudu pro detekci objektů i když se vůbec nic neděje a na kameře není žádný rozdíl? Možná potřebujeme odečítat čitače několikrát za vteřinu kvůli detekci anomálií, ale pro dlouhodobé zpracování nám stačí průměr za minutu, tak co ho počítat rovnou na zařízení? Druhým aspektem konektivity je latence a spolehlivost. Pokud můj senzor rozhoduje o životě a smrti strojů, protože dokáže včas zavřít trubku při nadměrném nárůstu tlaku, asi mě bude omezovat latence mezi zařízením a cloudem a ještě víc se budu strachovat o to, že třeba takové BLE má stejné fekvence jako mikrovlnka. Pokud je poškozené stínění tak budu muset doufat, že trubky nebudou zlobit zrovna když si někdo ohřívá krabičku s obědem. Někdy můžete říct, že konektivita je ve vašem případě levná a netřeba tedy šetřit - pojedeme třeba LTE a hotovo. Je tu ale druhý aspekt - spotřeba. Ta je závislá na množství přenesených dat a použité technologii. Rozdíl mezi speciální IoT přenosovou technologií a 100KB dat vs. LTE a 10MB dat je z hlediska spotřebované energie propastný. A pokud energie pochází z baterie nebo solárního panelu má to zásadní vliv na náklady (výměna baterky někde na věži v moři je drahá záležitost a výkon panelu koreluje s jeho cenou a možností rozumné fyzické montáže).
To by mi tedy dávalo smysl, ale zbastlit takové funkce do monilitického Céčka v Arduinu mě více než děsí. Chtělo by to něco čistšího. Něco, co je dobře modularizované a přenositelné mezi různými platformami. Stavební kostičky které si vyberu nebo vytvořím a propojím a to všechno mám vytvořené a nakonfigurované v cloudu. Pak jen řeknu na tento milion zařízení chci tyto moduly takto propojené a jedeme. To je Azure IoT Edge. Pro lokální zpracování potřebujete rozmný výkon, takže nejmenší Arduina použít nelze (nicméně mohou fungovat jako IoT zařízení). Nepotřebujete ale nutně Windows ani server. Začíná to s Raspberry, Linuxem a to může sloužit jako vaše IoT Edge zařízení a současně také jako lokální gateway pro případné méně inteligentní IoT vybavení. Stejně tak ale pro náročnější použití můžete použít x86/amd64 počítač s Linux nebo Windows.
Chceme tedy jednoduchý svět připojený do cloudu, do kterého nasazujeme moduly a všechno centrálně řídíme. Aby bylo něco takového možné budeme potřebovat jednotnou platformu a to je Azure IoT Edge. Není to speciální operační systém, ale sada služeb zejména v napojení na bezpečnost a samotná platforma běží v Raspberry (nebo jinde) jako Docker kontejner. Co zajišťuje?
V první řadě přináší zabezpečení, tedy základní platforma si kontroluje integritu spouštěných služeb a modulů, využívá integraci s bezpečnostními prostředky pro uložení klíčů a tak podobně.
Můžete samozřejmě použít takové zařízení jako koncový systém a napojit do něj přímo senzory třeba přes digitální vstupy I2C apod. IoT Edge ale funguje také jako malý Azure IoT Hub. Senzory (třeba Arduino), které můžete napojit přímo do velkého IoT Hub v Azure se dají prakticky stejným způsobem napojit na IoT Edge zařízení.
IoT Edge je připojeno na IoT Hub a pro jednotlivé moduly tak může zajišťovat bezpečnou šifrovanou a autentizovanou komunikaci s cloudem. Zajímavý je i koncept dvojčat. V cloudu (IoT Hub) můžete držet desired state, tedy požadované nastavení. Zařízení nemusí být zrovna online na to, abyste provedli nějakou změnu. Pokud se připojuje jen občas (loď v přístavu apod.), po připojení se srovná jeho stav se stavem požadovaným v cloudu a donatáhnou změny.
To pro funkčnost nejdůležitější je ale schopnost nasazovat moduly a směrovat zprávy mezi nimi.
Klíčovou funkcí je právě schopnost centrálně nasazovat moduly. Modul je ve finále Docker kontejner. Vývojáři ho připraví v jakémkoli systému, ale s Visual Studio Code získají potřebný skeleton na kliknutí. Kontejnerové obrazy se uloží do zabezpečeného repozitáře, ideálně Azure Container Registry, a vytvoří se cloudová konfigurace (deployment manifest). Pak jen řeknete, že těchto 1000 zařízení má mít těchto 5 modulů a je to. IoT Hub (cloud) při nejbližší příležitosti (hned jak se uslyší se zařízením) pošle informaci co se má spustit a IoT Edge to bezpečně udělá.
Ideální je mít v kontejneru IoT Edge SDK, protože to umožňí maximální funkce IoT Edge platformy (zabezpečení modulů, zasílání zpráv apod.). Ten je aktuálně dostupný pro C# (.NET Core), Node.JS a Python.
Při svém hraní využívám moduly na obsluhu základních komponent a jiné custom operace. Mám modul jehož smyslem je sbírat informace ze senzoru na digitálním portu a posílat je do IoT Edge frameworku. Pro každý senzor můžete mít separátní modul a krásně tak oddělit logiku od sebe (ve finále třeba pro GrovePi senzor použijete Python, ale pro jiný senzor budete preferovat .NET Core - to díky oddělenosti kontejnerů není nejmenší problém). Dále tam mám logiku pro ovládání displeje.
Custom moduly jsou perfektní pro implementaci práce se samotným senzorem a odeslání získaných dat do IoT Edge frameworku. Co se mi ale líbí úplně nejvíc jsou Azure moduly přinášející to co znáte z velkého Azure do vašeho Raspberry.
Než se k tomu dostaneme - klíčovou vlastností IoT Edge je messaging mezi moduly. Nemusíte řešit jak to udělat bezpečně a jak se bezpečně napojit do IoT Hub v Azure - to všechno pro vás perfektně dělá IoT Edge platforma. Modul může mít vstupní a výstupní zprávy - tak například můj modul pro nízkoúrovňové vyčítání senzoru má jen výstup. Ten na úrovni platformy můžete namířit do vstupu jiného modulu, například do modulu, který bude provádět filtraci (zahodí odečty teploty, které jsou mezi 20-30 stupni Celsia, protože nás zajímají jen hodnoty mimo toto rozmezí). Výstupem tohoto modulu je tedy filtrovaný proud informací a ten můžeme nechat poslat do IoT Hub jako výsledek (nebo prohnat dalšími moduly).
Azure Functions (v2) je framework na vytváření serverless aplikací a moderní rámec pro událostně řízené programování. Azure Functions mohou běžet jako čistě serverless v Azure, dokáží být na rezervované infrastruktuře (v Service Plan), můžete je mít lokálně na počítači, na serveru ve VM běžící kdekoli chcete a existuje právě i jejich IoT obdoba pro IoT Edge. Tak jak v Azure Functions můžete mít trigger třeba na zprávu v IoT Hub (tzn. nemusíte řešit napojení ani vyzvedávání zpráv, váš kód bude v pravý čas spuštěn a funkci se rovnou předá obsah zprávy) lze totéž udělat v IoT Edge. Pokud tedy potřebujete zavolat funkci když se objeví nová zpráva (třeba nové údaje z modulu obsluhujího senzor nebo nová zpráva ze vzdáleného připojeného IoT zařízení), je to extrémně jednoduché. Jednoduše vaše funkce zaklapne.
Pro práci s proudem dat je v Azure výborná služba Stream Analytics. Líbí se mi na ní, že přestože jde o proud dat, vy můžete svoje dotazy formulovat jakoby šlo o normální databázi. Formulace dotazů připomíná SQL a jak ji použít mi došlo během pár minut (zatímco pochopit logiku Storm mi přišlo podstatně složitější). Dá se s tím agregovat, konvertovat či detekovat základní anomálie. Tohle by se mi na krajním zařízení opravdu hodilo. Přesně na tohle je to udělané pro IoT Edge. Tak jak v cloudu pracujete se Stream Analytics, tak prakticky stejně budete pracovat s jeho variantou pro Edge. Jediný rozdíl je, že až budete mít dotazy vyladěné, celé se to zabalí do kontejneru a přes IoT Hub to nacpete do libovolného počtu IoT Edge zařízení.
Strojové učení je dnes k vidění čím dál častěji a dává to velký smysl. Trénování modelů je náročné a použití velkého Azure je pro něj naprosto ideální. Výsledný model, který umožní například vašim aplikacím předvídat chování, detekovat nežádoucí situace, rozpoznávat objekty nebo doporučovat vhodnou reakci, která vede k nejlepšímu výsledku, není nutně něco obludně velikého. Natrénovaný model můžete s Azure ML vyexportovat do kontejneru a to včetně varianty právě pro IoT Edge. Váš machine learning tak můžete z cloudu nainstalovat do milionu vašich IoT Edge zařízení.
IoT Edge je prefektní a bezpečný způsob distribuce logiky do krajního zařízení nebo IoT brány. V dalších článcích si to vyzkoušíme prakticky.