1.11 Riadiaci systém a softvér v systémoch IoT

Tok informácií

V IoT systémoch, rovnako ako v automatizácii, je možné komunikačný proces zjednodušene vyjadriť zápisom: vstup → akcia → výstup. Proces využíva vstupy na vykonanie takých akcií, ktoré dosiahnu požadovaný výstup. Výstupom teda v tomto kontexte nechápeme výstupný prvok, ale stav. Príkladom môže byť ventilačný systém s reguláciou teploty:

• vstupom sú senzory teploty, vlhkosti, CO₂ a prchavých organických látok;
• akčné prvky vykonávajú akcie ako zmena otáčok ventilátorov pre prúdenie vzduchu zvonku / cirkuláciu vo vnútri, zapnutie a vypnutie kúrenia / chladenia;
• výstupom je príjemná teplota a čistý vzduch.

Komunikačný proces môžeme realizovať rôzne:

a) Kontrolér realizuje vstupy i akcie, teda na základe údajov zo senzorov sám spúšťa akcie a tým dosahuje výstup. Takýto model označujeme edge computing (edge v tomto kontexte vyjadruje rozhranie systému a fyzického sveta) a je typický pre jednoduchú automatizáciu, dokonca aj z analógovej minulosti. Takto fungujú aj jednoduché spotrebiče, ako napríklad rýchlovarná kanvica na zohrievanie vody (vstupom je senzor teploty), či automatické svetlo (vstupmi sú senzory pohybu a svetla). Sprevádzkovanie takýchto spotrebičov je veľmi jednoduché, často nie je potrebná ani žiadna úvodná konfigurácia - zákazník si zariadenie kúpi, doma ho zapne a používa. Zo zariadení, ktoré sme používali v tomto kurze, sa jedná o zariadenia naprogramované cez ESPHome, ktoré samostatne vykonávali akcie na základe svojich vstupov.

b) Kontrolér poskytuje vstup, no na jeho základe nespúšťa žiadne akcie - namiesto toho údaje prenesie na vzdialený server. Takýto model nazývame cloud computing. Kontrolér je teda pripojený do internetovej siete. Server obvykle zbiera údaje z viacerých kontrolérov, má vysoký výkon a môže realizovať aj dlhodobé ukladanie a analýzu údajov. Server vyvoláva akcie odoslaním pokynu kontroléru. Nemusí sa (ale môže) jednať o ten istý kontrolér, ktorý realizuje vstup - jedným kontrolérom môže byť senzor pohybu (poskytuje vstup), druhým spínač osvetlenia (dosahuje výstup). Tento model používajú bežné smart zariadenia pre domácnosti - zákazník si ich zakúpi, cez svoju domácu sieť prepojí s cloud účtom výrobcu a pre ovládanie používa aplikáciu výrobcu. Celý proces inštalácie býva pomerne jednoduchý a intuitívny, zvládne ho aj bežný laik.

c) Fog computing je model takmer rovnaký ako cloud computing, no údaje sa neodosielajú do internetu. Kontrolér je pripojený len do lokálnej siete (nemusí to nutne byť IP sieť) a v nej je aj riadiaci server, napríklad v podobe SBC. S týmto modelom sme sa už stretli - na serveri bol systém Home Assistant a opäť sa mohlo jednať o zariadenie naprogramované cez ESPHome, ktoré však prijíma pokyny od servera. Výhodou je, že údaje neopúšťajú domácnosť / organizáciu a systém nie je závislý od výrobcu, či prevádzkovateľa služby. Nevýhodou je vyššia technická náročnosť realizácie, ktorá môže byť pre laikov neprekonateľnou prekážkou. Preto sa budeme venovať predovšetkým tomuto modelu.

Pri porovnaní týchto troch modelov môžeme vo všeobecnosti konštatovať, že edge computing je z hľadiska reakčnej doby (rýchlosti reakcie na podnet) najrýchlejší a cloud computing bude najpomalší. Vyplýva to z logického predpokladu, že čím bližšie k zdroju sa informácie spracovávajú, tým rýchlejšie dokáže systém vykonať zmenu. Lenže reakčná doba je ovplyvnená aj rýchlosťou spracovania údajov - pokiaľ sa jedná o komplexné spracovanie, napríklad aj s potrebou analýzy obrazu, do hry vstupuje aj výpočtový výkon a ten majú edge mikrokontroléry najnižší a s mnohonásobne výkonnejším cloud serverom nemôže súperiť.

Preto sa v praxi často používa kombinácia uvedených modelov:

• edge mikrokontrolér vykonáva najkritickejšie operácie, napríklad otvorenie výpustného ventilu pri príliš vysokom tlaku, zapnutie chladenia pri príliš vysokej teplote, spustenie sirény pri narušení objektu, spustenie hasiaceho systému pri zistení dymu a ohňa;
• lokálny fog server sa postará o výpočtovo náročnejšie operácie, napríklad analýza obrazu zo všetkých kamier v budove, vyhodnotenie celkovej teploty budovy zo všetkých senzorov, ukladanie údajov a generovanie grafov;
• vzdialený cloud server môže zbierať a analyzovať údaje z viacerých lokalít a prijímať rozhodnutia, napríklad regulovať tok do jednotlivých miest, presunúť rezervné kapacity na konkrétne miesta.

Spätná väzba

Pre ovládanie akčných prvkov, ktoré regulujú parametre prostredia, je potrebná spätná väzba (feedback) z tohoto prostredia. Napríklad pri ovládaní kúrenia a chladenia je potrebné sledovať, ako sa mení teplota. V komunikačnom procese sa výstup (napríklad ovplyvnenie teploty) dostáva do vstupu (meranie teploty). Rozlišujeme dva typy spätnej väzby:

Kladná / pozitívna spätná väzba býva nežiaducim problémom, ktorý destabilizuje systém, pretože na zvyšujúcu sa hodnotu vstupu (nechtiac) reaguje tak, že výstup ešte viac zvýši vstupnú hodnotu - výstup sa pripočítava k vstupu. Toto by sa stalo napríklad v prípade, že pri vyššej teplote by sme namiesto chladenia zapínali kúrenie - šlo by samozrejme o chybu v ovládacom programe alebo v zapojení prvkov. Reálne sa však môžeme s kladnou spätnou väzbou stretnúť v situácii, keď mikrofón zachytáva zvuk z reproduktorov a posiela ho cez zosilňovač opäť do reproduktorov, čo spôsobí nepríjemné pískanie (akustická spätná väzba). Podobná situácia môže nastať aj pri automatickej regulácii jasu displeja v tme - displeju sa nastavuje jas podľa okolitého svetla, lenže pri zobrazení bieleho obrazu sa osvetlí okolie, zariadenie reaguje zvýšením jasu, čo sa opakuje a o chvíľu je displej s plným jasom a ožaruje okolie.

Záporná / negatívna spätná väzba je presný opak - stabilizuje systém, vracia ho do rovnováhy, pretože na zvyšujúcu sa hodnotu vstupu regulátor (cielene) reaguje tak, že výstup znižuje vstupnú hodnotu. Toto je napríklad situácia, keď na zvyšujúcu sa teplotu reagujeme zvyšovaním otáčok ventilátora, čím znižujeme teplotu (za predpokladu, že ventilátor privádza chladnejší vzduch). Alebo tiež situácia, keď na zvyšovanie hladiny kvapaliny reagujeme uzatváraním ventilu prítoku - čo robí aj také jednoduché mechanické zariadenie, ako je splachovač vo WC nádržke.

Riadiaci systém, ktorý využíva spätnú väzbu na určenie, či bol dosiahnutý požadovaný výstup, označujeme ako systém s uzavretou slučkou. Existujú však aj jednoduché systémy bez spätnej väzby, tie označujeme ako systémy s otvorenou slučkou. Príkladom môže byť hriankovač, ktorý nezohrieva chlieb na nastavenú teplotu, ale zohrieva ho nastavenú dobu. Rovnako aj práčka, ktorá nezisťuje, či je prádlo už naozaj čisté, ale drží sa zvoleného programu.

Softvér v IoT

Z prostredia bežných počítačov sme zvyknutí, že sú vybavené operačným systémom, teda základným softvérom, ktorý umožňuje beh ďalšieho softvéru - aplikácií, poskytuje im rôzne služby a spravuje hardvérové zdroje počítača. Operačný systém dokonca pokladáme za nevyhnutný pre fungovanie počítača. V prípade mikrokontrolérov a zabudovaných (embedded) zariadení sa však situácia líši - operačný systém nie je nevyhnutnosť, často je zbytočný a z hľadiska zdrojov aj neefektívny, či priam nereálny. Obvykle nám stačí, že zariadenie realizuje jeden konkrétny program, ktorý sme naň nahrali vo forme binárneho kódu. Toto sa obvykle deje nahrávaním do flash pamäte, čo bežne nazývame „napaľovanie“ alebo „flashovanie“. Stretli sme sa s tým pri programovaní zariadení cez ESPHome.

Aplikácia na MCU bez OS sa musí postarať o všetko - napríklad nemôže požiadať o zobrazenie okna s textom, ale musí si sama inicializovať hardvér displeja, posielať mu obrazové informácie, ktoré si vopred pripraví v podobe bitovej mapy a rozsvieti každý jeden pixel tak, ako je treba.

Keďže sa hardvérové vybavenie MCU neustále zdokonaľuje, môžeme sa stretnúť aj s operačným systémom špeciálne navrhnutým pre mikrokontroléry - FreeRTOS.

Programovacie jazyky a spracovanie kódu programu

Binárny kód aplikácie v dnešnej dobe už samozrejme nemusíme písať priamo v inštrukciách cieľového procesora (teda v assembleri), ako bolo potrebné v počiatkoch počítačov - bolo by to značne neefektívne z hľadiska vynaloženého úsilia a využiteľnosti. Takýto program by bol totiž použiteľný len pre konkrétny typ procesora a nefungoval by na inom. Preto využívame univerzálne programovacie jazyky, ktorých kód je prevedený do binárneho kódu cieľovej architektúry CPU.

Pokiaľ sa program prevádza z programovacieho jazyka do binárneho kódu len raz - po „dopísaní programu“, tento proces prevodu nazývame kompilácia a programovací jazyk, ktorý to umožňuje, kompilovaný programovací jazyk. Patrí sem napríklad jazyk C / C++ (v prostredí MCU ide o Arduino IDE) a za zmienku stojí, že kompilácia sa nemusí vykonávať na cieľovom počítači, ba ani na počítači s rovnakou architektúrou CPU. Teda kompiláciu môžeme pokojne vykonávať aj na našom veľmi výkonnom osobnom počítači s architektúrou x86-64 a žiadať od neho, aby vygeneroval binárny kód napríklad pre RISC-V procesor - toto sme aj využívali pri programovaní ESPHome zariadení. Z vytvoreného binárneho kódu nie je možné získať pôvodný program, ba ani určiť, v akom jazyku bol pôvodne napísaný.

Veľmi populárnymi sa stali interpretované programovacie jazyky, ako sú napríklad Python (v prostredí MCU MicroPython a CircuitPython) a Javascript. Kód programu musí byť samozrejme tiež prevedený do kódu cieľového CPU, no nedeje sa tak vopred. V cieľovom zariadení sa spúšťa program v pôvodnom programovacom jazyku, prevod do binárneho kódu sa deje priebežne pri vykonávaní konkrétneho príkazu, či bloku - tento proces nazývame interpretácia.

Pojmy kompilácia i interpretácia by sme oba mohli preložiť ako „preklad“, no potom by sa zotieral zásadný rozdiel medzi nimi, preto používajme pôvodné pojmy.

Pri porovnaní oboch spôsobov prekladu programu z programovacieho jazyka si môžeme všimnúť viaceré rozdiely a výhody, z ktorých niektoré môžu byť v rôznych situáciách podstatnejšie a niektoré menej:

• vo všeobecnosti bude beh skompilovaného kódu rýchlejší ako interpretovaný program, no vďaka špeciálnym možnostiam interpreterov to nemusí vždy platiť;
• príprava (nahrávanie) je podstatne rýchlejšie pri interpretovanom programe - spomeňme si na zdĺhavé kompilácie ESPHome;
• testovanie je podstatne pohodlnejšie pri interpretovanom programe - stačí napísať príkaz a hneď vidíme výsledok, netreba nič nahrávať a chystať;
• nahrávaný kód je kratší pri interpretovanom programe - nemusí sa nahrávať kompletne celý program, ale len zmenený súbor, čo môže v praxi znamenať tiež značný rozdiel (flashovať binárny kód rádovo v MB vs. krátky program rádovo v kB).

Vizuálne programovanie

Doteraz spomínané programovacie jazyky, kompilované i interpretované, predstavujú „klasické“ programovanie v podobe textových príkazov daného jazyka. V posledných rokoch sa však výrazne rozmáha aj takzvané vizuálne alebo blokové programovanie, pri ktorom sa nepíšu príkazy, ale prepájajú algoritmické bloky. Toto umožňuje ľahšie vkročiť do sveta programátorov aj ľuďom, ktorí nemajú žiadne skúsenosti s programovaním a chcú si prispôsobiť správanie zariadení presne tak, ako potrebujú. Aj takáto jednoduchá forma programovania im otvára nové možnosti.

S blokovým programovaním sme sa zatiaľ nestretli, no využívajú ho aj vzdelávacie nástroje, ako napríklad Scratch a bežne sa v blokoch MakeCode programuje micro:bit. Časom sa ním stretneme v nástroji Node-RED, ktorý umožňuje programovanie komplexnejších IoT systémov. Mimochodom, program zostavený z vizuálnych blokov v Node-RED je interpretovaný v jazyku Javascript.