Use Case: Smart Waste Management

Máme problém…

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

  

• (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].

  

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.

  

• 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.