Čo je a o čom je IoT?

nie príliš stručný úvod do IoT, štvorvrstvová architektúra IoT riešení, analýza a syntéza problému, krátko o hardvéri, spotrebe, komunikácii, dátovej analytike a strojovom učení, aktualizáciách, bezpečnosti

Záznam z prednášky

Čo je to IoT?

  • (slide) Začnem teda rovno otázkou: “Čo je to IoT?”

  • Ja sám neviem (a preto to učím).

  • Problém je totiž v tom, že aj napriek tomu, že tento termín existuje od roku 1999, dodnes neexistuje obecne uznávaná definícia tohto pojmu, ale len akési opisné charakteristiky. Tie majú častokrát niečo spoločné, ale často si dokonca odporujú.

  • (slide) Tak napríklad - jedna z najvoľnejších definícií je:

    Internet of Things (IoT) means any smart device with ability to communicate via Internet. – by iotbuzzer.com

  • Túto charakteristiku by sme vedeli voľne preložiť ako:

    Internet vecí predstavuje akékoľvek zariadenie so schopnosťou komunikovať prostredníctvom internetu.

  • Tá voľnosť spočíva v tom, že na základe tejto definície je zariadením IoT napríklad aj mobilný telefón. Stretnete sa však s množstvom príspevkov a úvah, v ktorých autori hovoria o tom, prečo napríklad mobilný telefón nepovažujú za IoT zariadenie.

  • (slide) Pre naše potreby však budeme používať túto definíciu:

    The Internet of Things (IoT) is a system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. – by iotagenda

O čom všetkom je IoT?

  • (slide) IoT nie je len o hardvéri. A rovnako tak nie je len o softvéri. Je to skôr balík služieb s pridanou hodnotou.

Máme problém…

  • Aby sme si uvedomili, čo všetko je IoT, skúsime si to prezentovať na konkrétnom probléme.

    Smart Waste Service (zdroj)
  • (slide) Jednou z úloh mesta, je zabezpečiť službu pre vývoz smetí z kontajnerov. Táto služba niečo stojí a mesto každoročne platí za túto službu nejaký poplatok. Samozrejme - výška poplatku sa bude odvíjať od počtu vývozov jednotlivých kontajnerov. V princípe to poznáte - smetiarske auto chodí vyvážať vaše smeti pravidelne v určité dni. Nechodí teda každý deň, nechodí niekoľkokrát do dňa, chodí napr. 3x do týždňa - v pondelok (po víkende), v stredu a v piatok (pred víkendom). To teda znamená, že ak vyvezenie jedného kontajneru stojí domácnosť 1 Euro, tak služba stojí týždenne 3 Eurá, mesačne 12 Eur, ročne 144 Eur.

  • V konečnom dôsledku poplatky za túto službu zaplatí občan, ale aj tak sa mesto snaží službu dojednať za čo najnižšiu cenu. Takže problém je z tohto pohľadu jasný - dostať za službu čo najnižšiu cenu.

Analýza problému

  • Ak však začneme nad problémom rozmýšlať, veľmi rýchlo si všimneme, že cena je závislá od počtu výjazdov smetiarskeho auta. Ak teda znížime počet výjazdov, zníži sa automaticky aj cena. Aktuálne je systém nastavený tak, že máme 3 výjazdy do týždňa, čo stojí domácnosť 12 Eur mesačne. Ak by sme počet výjazdov znížili o 1 (napr. v stredu už auto chodiť nebude), cena služby sa zníži na 8 Eur za mesiac.

  • Cenu sme síce znížili, ale

    • čo ak každý piatok budú kontajnery také plné, že sa do nich smeti už proste nevojdú a budú “pretekať” obsahom?
    • čo ak naopak budú aj napriek tejto úspore kontajnery neustále prázdne a smetiarske autá vyjdú vždy len ku prázdnym kontajnerom?
  • Cenu síce ovplyvníme, ale samotná služba sa v prvom prípade výrazne zhorší a v druhom prípade budeme stále platiť za vývoz prázdneho kontajneru. Je jasné, že cena je priamo závislá od počtu výjazdov, ale nechceme, aby auto

    • chodilo ku prázdnemu kontajneru
    • prišlo ku košu na základe časového intervalu a nie vtedy, keď je kontajner plný
  • No a potom tu môžu byť obyvatelia, ktorí produkujú výrazne viac smetí ako iní, čo znamená, že tí občania, ktorí neprodukujú veľa odpadu, budú doplácať na tých, ktorí produkujú veľa odpadu. Alebo - čo ak ľudia z vedľajšieho vchodu budú smeti vysýpať do našich kontajnerov, aby u nich znížili cenu a naopak ju navýšili nášmu vchodu? Ako by sme docielili spravodlivosť?

  • (slide) Znížením počtu vývozov smetí a tým pádom ušetrením peňazí obyvateľov, sa v roku 2021 rozhodla ísť aj Bytča. Aj keď zámer je ušľachtilý spolu so zámerom naučiť občanov separovať odpad, množstvo odpadu sa tým samozrejme nezníži. Zvýši sa len množstvo plných kontajnerov s “pretekajúcim” obsahom, výsledkom čoho sú sťažnosti a nespokojnosť obyvateľov [@s72].

    Bytča znížila intenzitu vývozu odpadkov, obyvatelia sa sťažujú [@s72]

Syntéza problému

  • Ak chceme ušetriť a pritom zachovať službu kvalitnou, nestačí len fixne znížiť počet výjazdov, ale vhodne ich optimalizovať, resp. nastaviť. Potrebujeme teda vytvoriť riešenie, vďaka ktorému príde smetiarske auto vyviezť odpad len vtedy, keď bude kontajner plný. Tým pádom predídeme obom uvedeným problémom:

    • auto nepríde zbytočne ku prázdnemu košu, ale príde až vtedy, keď sa naplní
    • auto príde ku kontajneru až vtedy, keď ho bude potrebné vyprázdniť.
  • Aby sme tento cieľ dosiahli, potrebujeme vytvoriť zariadenie, ktoré:

    • bude súčasťou kontajnera,
    • bude v pravidelných intervaloch zisťovať zaplnenosť kontajnera, a
    • po zistení zaplnenia kontajnera bude posielať dáta do vzdialeného úložiska/databázy/cloud-u, aby sa tieto mohli analyzovať a v prípade potreby mohlo vyštartovať smetiarske auto (nie hneď, ale jeho výjazd je potrebné naplánovať)
  • Samozrejme časťou úlohy bude následne aj naplánovanie vhodnej trasy pre samotné smetiarske autá. Ich trasa bude totiž zakaždým iná, nakoľko budú chodiť iba k plným kontajnerom. Systém sám na základe aktuálnych údajov vie určiť trasu aj počet kontajnerov, ktoré zvládne auto vyviezť.

  • A kto vie - možno nie je efektívne posielať smetiarske autá vždy len od kontajnera ku kontajneru, ktoré môžu byť od seba vzdialené kilometre. Možno sa dajú náklady vývozu znížiť tak, že auto spolu s plne obsadeným kontajnerom odvezie odpad zo všetkých kontajnerov, ktoré sa nachádzajú na rovnakej ulici. Keď už je tam, tak nech jednou jazdou vyvezie čo najviac. O výhodnosti alebo nevýhodnosti tejto úvahy nám však budú vedieť povedať až dáta.

Hardvérová časť problému

  • Ako teda zistíme, či je kontajner dostatočne naplnený?

  • (slide) Ak by sme použili senzor, ktorým budeme merať hmotnosť, nebudeme veľmi úspešní. Môže sa totiž veľmi jednoducho stať, že kontajner zapraceme polystyrénom, veľmi rýchlo vyplníme jeho objem, ale celková hmotnosť takéhoto odpadu, bude veľmi nízka. Ak však do neho začneme sypať stavebný odpad, veľmi rýchlo môže kontajner dosiahnuť svoj hmotnostný limit aj napriek tomu, že je takmer prázdny. Tento aspekt však zanedbáme, nakoľko na stavebný odpad sú vyhradené osobitné kontajnery, zberné dvory (a na Slovensku samozrejme aj voľná príroda všade okolo).

  • (slide) Miesto merania hmotnosti odpadu v kontajneri bude výhodnejšie zisťovať jeho obsadenosť meraním výšky odpadu v ňom. Preto do najvyššieho bodu v kontajneri umiestnime senzor merajúci vzdialenosť. Ten v prípade prázdneho kontajnera odmeria vzdialenosť medzi najvyšším bodom v kontajneri a jeho dnom. S pribúdajúcim odpadom sa bude táto vzdialenosť zmenšovať, takže čím menšia táto vzdialenosť bude, tým plnší bude aj kontajner.

  • Samozrejme - je možné uvažovať aj nad kombináciou oboch riešení. Tým sa síce riešenie predraží, ale môže pomôcť predísť problému s preťažením kontajneru.

  • (slide) Takže IoT je aj o hardvéri.

Nízka spotreba v zariadeniach

  • (slide) Jednou z výziev, ktorú so sebou priniesla oblasť IoT je aj nízka spotreba alebo z angl. low power. Je totiž potrebné si uvedomiť, že pri inštalácii riešenia už nebudeme mať k dispozícii trvalý zdroj elektrickej energie, ale budeme odkázaní len na zdroj napätia z batérie. Preto je potrebné zohľadniť aj tento aspekt a pripraviť riešenie tak, aby dokázalo vydržať na batérie čo najdlhšie.

  • Zvýšenie výdrže je samozrejme priamoúmerné aj tomu, koľko ďalších akčných členov alebo senzorov budeme mať pripojených a teda napájaných z batérií. Netreba zabúdať, že hlavne komunikačné moduly majú pomerne vysokú spotrebu. Preto je dobré spúšťanie, resp. prácu s nimi plánovať a pokiaľ nie sú potrebné, je dobré ich vypínať.

  • Aj z pohľadu nášho návrhu je jasné, že nie je potrebné, aby zariadenie pracovalo neustále. Výška hladiny v kontajneri sa nemení niekoľkokrát za sekundu, ale možno niekoľkokrát za hodinu, aj to najmä cez deň. Poprípade len vtedy, keď dôjde k otvoreniu kontajnera. Po zvyšok tohto času by bolo dobré, aby zariadenie nerobilo nič a čakalo len na zmenu.

  • Dosiahnuť čo najnižšiu spotrebu je možné viacerými spôsobmi. Ako som už spomínal - jeho spotreba sa zvyšuje s množstvom ďalších pripojených prvkov. Čo najdlhšiu prevádzku je možné zabezpečiť samozrejme batériou s najväčšou kapacitou, pridaním solárnych článkov ako zdroja energie, ale aj uspatím zariadenia a jeho zobudením buď po uplynutí časového intervalu alebo pri vzniku externej udalosti (napr. pri otvorení kontajneru). Zvýšiť výdrž zariadenia je možné aj znížením pracovnej frekvencie mikrokontroléra.

  • (slide) Takže IoT je aj o nízkej spotrebe.

Komunikácia medzi zariadeniami

  • (slide) Keď kontajner odmeria výšku odpadu, je potrebné aktuálny stav poslať dispečingu, aby v prípade potreby bolo možné vyslať alebo aspoň naplánovať jazdu smetiarskeho auta.

  • Tento problém veľmi úzko súvisí s predchádzajúcim - držať neustále otvorené spojenie s dispečingom sa “úspešne” podpíše na spotrebe. Ako sme už spomínali, resp. analyzovali vyššie, nemá zmysel, aby zariadenie výšku hladiny odpadkov v kontajneri sledovalo neustále, ale stačí v pravidelných intervaloch, resp. pri otvorení kontajnera. Taktiež samotné údaje nie je nutné posielať pri každom meraní, ale napr. niekoľkokrát za deň. Určite však vtedy, ak bola hladina pre zabezpečenie vývozu odpadu dosiahnutá.

  • Pri realizácii spojenia s dispečingom je samozrejme potrebné poznať lokalitu a možnosti spojenia. Keďže sa jedná o externé prostredie, nedá sa spoľahnúť na dosah WiFi signálu v každom kontajneri. Rovnako ešte stále môžu existovať lokality, ktoré nie sú pokryté ani mobilným signálom. Do úvahy prichádzajú aj siete, ktoré sú určené priamo pre využitie v oblasti IoT, ako napr. Lora alebo Sigfox. V “najhoršom” prípade môžu kontajnery oznamovať svoj stave okolitým zariadeniam (smetiarskym autám) cez technológiu Bluetooth LE.

  • Pre IoT samozrejme existujú aj špecifické komunikačné protokoly, ako napr. MQTT alebo CoAP. Veľmi populárne je však na niektoré účely používať aj REST API komunikujúce prostredníctvom protokolu HTTP.

  • (slide) Takže IoT je aj o komunikácii.

Analýza dát, strojové učenie a vizualizácia dát

  • (slide) Dnes sa stala neoddeliteľnou súčasťou problematiky IoT aj dátová analytika, poprípade strojové učenie.

  • Zatiaľ sme hovorili o jednom kontajneri a o jednom smetiarskom aute. Pre ilustráciu predpokladajme, že kontajner bude posielať údaje o aktuálnom stave každú hodinu. To je teda 24x za deň. Pred domom (hlavne teda bytovkou) stojí týchto kontajnerov aspoň 5 - 2 pre komunálny odpad, 1 pre papier, 1 pre plasty a 1 pre sklo. Ak pre každý z nich bude platiť rovnaký predpoklad, tak dokopy z týchto kontajnerov denne odíde 120 správ. To číslo je ešte stále veľmi malé. Ale predpokladajme, že v meste je minimálne 2000 budov s rovnakými vlastnosťami. Pri rovnakom predpoklade je to už spolu 24000 správ denne.

  • Samozrejme, tieto údaje sú stále pomerne malé. Ale poskytujú predstavu, že z malého problému sa pomaly môže stať celkom veľký.

  • Tu samozrejme ide o to, čo všetko si chceme o danom kontajneri pamätať. Ak chceme len vyhodnotiť jeho stav, nepotrebujeme ani databázu. Ak však budeme údaje o kontajneroch ukladať, môžeme tieto údaje analyzovať v čase a vytvárať tak predikcie. Rovnako tak môže byť systém výberu peňazí za odpad nastavený spravodlivejšie, keďže samotní obyvatelia si budú môcť overiť, koľko reálnych vývozov bolo vykonaných počas roka.

  • Z dát sa dajú získať rozličné informácie, ako napr. ak za týždeň systém nehlási zmenu vo výške hladiny smetí, dá sa predpokladať, že je domácnosť na dovolenke. Ak sa papier spred domu odváža len raz mesačne a kontajner hlási dosiahnutie limitu už po dvoch týždňoch, tak buď sa upratovalo, sťahovalo alebo oslavovalo. Rovnako tak dispečing vie plánovať údržbu či už vozidiel, kontajnerov alebo samotných zariadení podľa získaných údajov tak, aby nijako službu neovplyvnili.

  • Aktuálne údaje sú teda veľmi potrebné. Umožňujú rovnako optimalizovať aj výjazdy samotných smetiarskych áut. Ak systém vie, ktoré kontajnery sú plné a koľko objemu smetí predstavujú, vie naplánovať jazdu auta tak, aby vyviezlo toľko odpadu, koľko sa do neho vojde. A to celé s určením optimálnej trasy pre každé jedno smetiarske auto s využitím údajov o aktuálnej dopravnej situácie.

  • (slide) Práca s údajmi súvisí aj s výberom vhodného databázového systému. Stále je síce možné použiť relačné databázy, ale v oblasti IoT začínajú mať stále viac navrch nerelačné databázové systémy (tzv. NoSQL databázové systémy). V tejto súvislosti sa používajú napr. tzv. Time Series databázové systémy.

  • Prepojenie databázových systémov a analytických systémov s vizualizačnými nástrojmi je už len bonus.

  • (slide) Takže IoT je aj o zbere, analýze a vizualizácii údajov.

Aktualizácie softvéru a hardvéru

  • (slide) Životný cyklus riešenia ráta aj s tým, že softvér zastaráva a nachádzajú sa v ňom chyby. To isté platí aj o hardvéri. Aj v tejto oblasti treba rátať s tým, že softvér treba aktualizovať a v prípade potreby hardvér vymeniť.

  • Aktualizáciu softvéru dôverne poznáme. Či už z pohľadu operačného systému alebo z pohľadu používaného softvéru. Aktualizácie je možné riešiť automaticky bez nutnosti zásahu používateľa, ktorý je na konci len oboznámený s tým, že softvér bol aktualizovaný, alebo je potrebné aktualizáciu povoliť, resp. ju vykonať ručne.

  • Rovnako sa dá pozerať aj na aktualizáciu IoT riešení. Softvérová aktualizácia dispečingu predstavuje proces bežnej aktualizácie softvéru. Tú pravú výzvu však predstavuje aktualizácia samotných vecí, ktorých budú v našom prípade a prevedení tisíce.

  • Určite nebudeme chcieť, aby bolo nutné vykonávať aktualizácie manuálne. Hlavne nie vtedy, ak hlavne v počiatku zavádzania systému môže byť aktualizácií aj viac. Áno - aktualizácie môžu vykonávať priamo smetiari, kde počas výjazdu auta bude k dispozícii jeden technik, ktorý sa k zariadeniu vždy pripojí a aktualizáciu vykoná. Tým sa však predĺži samotný výjazd a aj cenové náklady služby môžu byť vyššie. Rovnako tak je potrebné vedieť, kde je aká verzia systému a ľahko sa môže stať, že kontajnery, ktoré sa vyvážajú len príležitostne, môžu byť niekoľko verzií pozadu za aktuálnym vývojom.

  • (slide) Tu je priam žiadúce hľadať spôsoby, ako tento problém automatizovať. Bežne poznáme tzv. OTA aktualizácie (z angl. Over the Air Updates), kedy sa v prípade vydania novej verzie systém zariadenia aktualizuje sám. Tým pádom môžeme aktualizácie plánovať a celé mesto aktualizovať v priebehu niekoľkých hodín, resp. v priebehu noci, kedy v prípade zlyhania aktualizácie dokáže ešte servis k nesprávnej aktualizácii vycestovať a tak zabezpečiť bezproblémový chod služby cez deň.

  • Samozrejme - hardvérová aktualizácia si vyžaduje zásah priamo na mieste. Či už v prípade výmeny končiacich batérií alebo v prípade poškodenia zariadenia (napr. ak sa zariadenie neozvalo 3x po sebe (vychádzajúc z našej ilustrácie to znamená, že sa neozvalo počas posledných troch hodín).

  • (slide) Takže IoT je aj o aktualizáciách - či už softvérových alebo hardvérových.

Bezpečnosť

  • (slide) V neposlednom rade netreba podceniť otázku bezpečnosti v IoT zariadeniach a riešeniach. Práve vďaka popularite a rýchlemu rozmachu tejto oblasti sa otázke bezpečnosti nevenuje toľko pozornosti, koľko by sa malo. A už teraz nájdete mnoho článkov opisujúcich časté problémy alebo najpopulárnejšie prieniky práve vďaka podceneniu bezpečnosti.

  • (slide) Rovno začnem príkladom, ktorý sa reálne stal v jednom nemenovanom kasíne. Toto kasíno v ňom malo umiestnené akvárium a v ňom sa nachádzal termostat pripojený do siete kasína. Hackeri objavili exploit v tomto termostate, vďaka ktorému sa dostali do siete kasína (foothold). Následne sa dostali k databáze hráčov, ktorú následne cez ich sieť stiahli, cez termostat dostali von a následne ju nahrali na cloud.

    Hackers steal casino’s customer data via connected fish tank [@s2]
  • Bezpečnosť sa teda v tomto prípade netýka len samotného koncového zariadenia. Bezpečnosť sa týka aj celkovej architektúry alebo napríklad aj toho, v akej sieti sa IoT zariadenia nachádzajú, ak sa jedná napr. o nasadenie vo verejnom priestore. Nie je totiž najlepší nápad pripojiť IoT zariadenia do rovnakej siete, v ktorej sa nachádzajú aj návštevníci napr. reštaurácie alebo hotela.

  • Obecne môže byť problém podpora softvéru zo strany výrobcu, keď sa po istom čase proste na podporu zariadenia vykašle. Rovnako je tak aj o tom, ako často a ochotne správcovia siete a pripojených zariadení tieto zariadenia aktualizujú.

  • (slide) Takže IoT je aj o bezpečnosti.

Architektúra IoT riešení

  • (slide) Zatiaľ čo každé IoT riešenie je rozdielne, základ ich architektúry ako aj smer toku údajov, je viacmenej rovnaký. Architektúra IoT riešenia pozostáva zo štyroch častí/vrstiev/fáz, ktoré sú znázornené na nasledovnom obrázku:

    IoT Architecture Overview [@s4]
  • V prvom rade pozostáva z vecí, resp. objektov, ktoré sú pripojené do internetu. Tie pomocou ich zabudovaných senzorov a akčných členov sledujú svoje okolie a získavajú o ňom informácie.

  • Tieto informácie sú následne odosielané do tzv. IoT brán (z angl. IoT gateway). Nasledujúca fáza pozostáva zo systémov na zber údajov a brán, ktoré zbierajú obrovské množstvo nespracovaných údajov, ktoré následne konvertujú do digitálnych tokov dát (z angl. stream), filtrujú ich a predspracúvajú tak, aby boli pripravené pre analýzu.

  • Tretia vrstva je reprezentovaná tzv. edge zariadeniami, ktoré sú zodpovedné za ďalšie spracovanie a pokročilú analýzu dát. Na tejto vrstve môže do procesu spracovania údajov vstúpiť strojové učenie a vizualizácia.

  • Nakoniec sa údaje dostanú do dátových centier, ktoré môžu byť buď v cloud-e alebo inštalované lokálne. Toto je miesto, kde sú údaje ukladané, spravované, hĺbkovo analyzované, aby z nich bolo možné získať užitočné informácie.

  • Poďme sa pozrieť na jednotlivé vrstvy podrobnejšie.

1. vrstva: Veci, senzory a akčné členy

  • (slide) Každý IoT systém pozostáva z prepojených zariadení, ktoré produkujú údaje. Podobne je tomu aj v našom prípade služby zabezpečujúcej chytrý vývoz smetí. V tejto vrstve sa nachádzajú zariadenia umiestnené priamo v kontajneroch, ktoré sú pripojené do siete internet.

    IoT Architecture: Stage 1 [@s4]
  • Obecne však tieto zariadenia nemusia nutne komunikovať len so zariadeniami nachádzajúcimi sa na vyššej vrstve (gateway), ale môžu komunikovať aj so zariadeniami na tejto vrstve. Niektoré zariadenia totiž pre svoju činnosť potrebujú informácie od ďalších zariadení. To môže byť napr. poplašné zariadenie, kde senzor pohybu môže dať vedieť o tom, že zaznamenal pohyb, čo môže byť signál pre svetlá, aby sa rozsvietili a pre reproduktory, aby začali robiť hluk. Nie je nutné, aby pokyn na to došiel až z cloud-u a teda aby dáta prešli cez všetky vrstvy a cez “celý” internet.

2. vrstva: IoT Brány a zber dát

  • (slide) Zariadenia na tejto vrstve sa nachádzajú (z geografického pohľadu) veľmi blízko ku zariadeniam z predchádzajúcej vrstvy. Môže to byť zariadenie v inteligentnej domácnosti, zariadenie na pracovisku alebo v budove a pod.

    IoT Architecture: Stage 2 [@s4]
  • Z pohľadu funkčnosti je však dôležité sa na tieto zariadenia pozerať ako na samostatnú vrstvu v IoT architektúre, pretože je kľúčová pre spracovanie údajov, ich filtrovanie a prenos takto pripravených údajov ďalej do edge infraštruktúry, poprípade rovno do cloud-u.

  • Brány hrajú dôležitú úlohu v riešeniach, kde je použité obrovské množstvo vecí, ktoré produkujú obrovské množstvo údajov. Ak by napr. náš projekt s chytrými kontajnermi bol úspešný a bol by nasadený na celom Slovensku, množstvo údajov, ktoré by kontajnery generovali a následne posielali priamo do cloud-u, by bolo obrovské. Výsledkom by mohlo byť zahltenie serveru požiadavkami a tým pádom znefunkčnenie služby. Preto jednou z najdôležitejších úloh brán je tento nápor údajov na vyššie vrstvy znížiť. Okrem toho vykonajú aj prvé predspracovanie a filtrovanie údajov, ktoré následne odošlú vyšším vrstvám v kompaktnom a dohodnutom formáte. Množstvo prenášaných údajov je teda menšie a vyššie vrstvy sa už predspracovaním údajov nemusia zaoberať.

  • Použitie brán taktiež zvyšuje bezpečnosť celej infraštruktúry. Keďže brány zabezpečujú tok údajov oboma smermi (aj na vyššie aj na nižšie vrstvy), použitím vhodného šifrovania môžu zabrániť prípadnému úniku dát z vyšších vrstiev. Rovnako tak znižujú riziko útokov na samotné IoT zariadenia, resp. veci pracujúce na nižších vrstvách.

  • Na tejto vrstve je možné poskytnúť aj prvé vizualizácie koncovým používateľom.

3. vrstva: Edge analytika

  • (slide) Táto vrstva sa zvykne nazývať aj Edge IT alebo Edge Computing alebo skrátene len Edge. Termín Edge Computing je známy už z neskorých 90-tych rokov s príchodom služieb na doručovanie obsahu (napr. video), kedy sa v rámci zníženia záťaže presúvali servery bližšie k používateľovi.

  • Definícia podľa Wikipedie znie [@wikipediaEdgeComputing]:

    Edge computing is a distributed computing paradigm which brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth.

    Voľne by sme túto definíciu mohli preložiť nasledovne:

    Edge computing reprezentuje paradigmu distribuovaného výpočtového systému, kde je snaha dostať výpočtové uzly spolu s úložiskami čo najbližšie k cieľovým zariadeniam s cieľom zvýšiť reakčnú dobu a znížiť množstvo prenášaných dát.

  • (slide) Podobný zámer má aj tretia vrstva v IoT architektúre - systémy pracujúce na edge vrstve dokážu poskytnúť rýchlejšie odpovede a zabezpečiť vyššiu flexibilitu v spracovaní a analýze údajov. Ďalej teda analyzuje a spracováva údaje a pripravuje a následne ich synchronizuje s dátovými centrami (štvrtá vrstva).

    IoT Architecture: Stage 3 [@s4]
  • Zariadenia tejto vrstvy majú výrazne viac systémových prostriedkov ako zariadenia na predchádzajúcej vrstve. Ich umiestnenie môže byť stále pomerne blízko samotným zariadeniam/veciam. Rovnako však môžu byť zariadenia umiestnené aj vo vzdialených kanceláriách, resp. budovách spoločnosti.

  • Táto vrstva môže poskytovať vizualizácie pre koncových používateľov.

  • Keďže rýchlosť pri poskytovaní dátovej analytiky hrá v istých odvetviach kľúčovú rolu, stáva sa edge vrstva veľmi populárnou hlavne v priemysle. Nie je však nutnou súčasťou každej IoT architektúry.

4. vrstva: Dátové centrá a klaudové platformy

  • (slide) Zariadenia tejto vrstvy sú navrhnuté pre uchovávanie, spracovanie a analyzovanie obrovských objemov údajov. Sú vybavené výkonnými systémami zabezpečujúcimi hĺbkovú dátovú analýzu a strojové učenie nad dátami. Zariadenia na edge vrstve nemajú dostatočný výkon na zvládnutie týchto operácií.

    IoT Architecture: Stage 4 [@s4]
  • Výhodou cloudových riešení je napríklad vysoká dostupnosť, zníženie neplánovaných výpadkov, spotreba energie (netreba riešiť na strane klienta) a iné.

  • Na tejto vrstve sa nachádzajú aj koncové aplikácie pre používateľov. Tie tak dokážu poskytovať business intelligence ako aj prezentačnú vrstvu. Vďaka nej môžu používatelia so systémom interagovať, môžu ho ovládať, monitorovať a umožňuje im prijímať ďalšie rozhodnutia vďaka rozličným reportom, dashboardom a informáciám získaným v reálnom čase.

  • Zariadenia na tejto vrstve sa môžu nachádzať geograficky vo veľmi veľkej vzdialenosti od samotných vecí (napr. môžu byť umiestnené na rozličných kontinentoch), z ktorých dáta zbierajú, analyzujú a prípadne aj ovládajú.

Štvorvrstvová IoT architektúra

  • (slide) Ak to teda zhrnieme, celkový pohľad na IoT architektúru môže vyzerať nasledovne:

    IoT Architecture [@s6]
  • Nie každé riešenie však nutne musí obsahovať všetky vrstvy. Pre jednoduchšie riešenia si vystačíte dokonca len s prvou a poslednou vrstvou. Ak samozrejme nechcete, aby údaje opúšťali vašu lokalitu, vystačíte si s prvou a druhou vrstvou, kde gateway bude zabezpečovať aj úlohy poslednej vrstvy.

Záver

  • (slide) Internet vecí teda nie je len o elektronike, aj keď je aj o nej. Rovnako tak nie je len o softvéri, aj keď aj o ňom je IoT. Svet IoT je však aj o ďalších veciach, ktoré sme spomínali. Je aj o údajoch, ich interpretácii a vizualizácii. Je aj o aktualizáciách a bezpečnosti, aby sme sa vďaka tomu, že chceme byť in nevystavili riziku a možno aj svojich klientov.

  • (slide) O tomto všetkom je IoT. Na začiatku sme si predstavili jednu opisnú charakteristiku IoT, ktorú budeme rešpektovať. Okrem toho všetkého je však IoT hlavne o pridanej hodnote. O niečom navyše.

  • Toto všetko pekne zhrnul v definícii Pavel Pohanka, ktorý hovorí, že:

    Internet vecí predstavuje sieť prepojených objektov (vecí), ktoré sú jednoznačne adresovateľné s tým, že táto sieť je založená na štandardizovaných komunikačných protokoloch umožňujúcich výmenu a zdieľanie údajov a informácií, ktorých analýzou bude možné docieliť vyššiu pridanú hodnotu. [@s78]

  • Pokúsme sa teda nájsť pridanú hodnotu v službe poskytujúcej chytrý vývoz odpadu, o ktorej sme dnes hovorili celý čas:

    • Základná hodnota služby zostáva nezmenená. Je ňou samotný jej cieľ, a teda - vývoz odpadu, o ktorý sa ja ako spotrebiteľ nestarám.

    • Pridanou hodnotou bude určite znížená a spravodlivá cena, kde sa zohľadní množstvo reálne vyvezených smetí.

    • Vyššia cena služby môže motivovať k zamysleniu sa nad množstvom produkovaného odpadu a snaha o jeho zníženie.

    • Optimalizácia samotného vývozu, takže menej smetiarskych áut v uliciach, nižšie emisie a pre prevádzkovateľa služby sú to rozhodne znížené náklady.

  • (slide) Služba chytrého vývozu odpadu nás bude sprevádzať predmetom a budeme všetko konfrontovať práve s ňou. A aby ste si nemysleli, že je to len taká pseudo vymyslená služba, firma, ktorá poskytuje takéto riešenie sa volá SENSONEO a je zo Slovenska. Demo video nájdete na YouTube. Príspevok zástupkyne spoločnosti na podujatí DebaTech 2021 nájdete rovnako na YouTube.