POST

• (slide) Keď sa zapne počítač, spustí sa POST - Power-On Self-Test. Je to diagnostický proces, ktorý sa spúšťa vždy pri spustení alebo reštartovaní zariadenia. Jeho hlavnou úlohou je vykonať sériu kontrol na overenie správnej činnosti základných hardvérových komponentov pred zavedením operačného systému.

• (slide) V prípade, že dôjde k problému, proces zavádzania systému sa ukončí.

• (slide) POST test je príkladom samodiagnostiky resp. autodiagnostiky, z angl. self-test. Jedná sa o proces, pri ktorom zariadenie kontroluje svoje vlasnté funkcie bez nutnosti zásahu používateľa. To môže zahŕňať:

  • kontrolu hardvéru - napr. funkčnosť senzorov, akčných členov, batérií, komunikačných modulov, …
  • test softvéru - napr. overenie integrity komponentov systému, čím overíme napr. úspešnosť aktualizácie systému (mohla byť chybná alebo neúplná)
  • bezpečnostné kontroly - napr. monitorovanie systémových bezpečnostných nastavení a tým pádom možná detekcia útoku alebo porušenia bezpečnosti (napr. kontrolné sumy uložených údajov)

• (slide) Príkladom samodiagnostiky sú napr. automobily, ktoré samodiagnostiku vykonávajú pri otočení kľúča do polohy 1. Výsledok samodiagnostiky je vidieť na palubovke auta.

• Pri otočení kľúča a spustení samodiagnostiky dôjde k nasledovným testom:

  • Rozsvieti palubovka - Všetky notifikačné LED diódy sa rozsvietia, aby bolo zrejmé, že v prípade vzniku problému notifikačná LED dióda bude svietiť. Ak sa totiž LED dióda pri spustení samodiagnostiky nerozsvieti, je zrejme pokazená, čo znamená, že nebudeme notifikovaní v prípade vzniknutia problému, na ktorý mala poukázať.

  • Rozozvučí sa bzučiak - Niektoré notifikácie sú signalizované aj zvukom. Ak je teda bzučiak pokazený, nebudeme na ne upozornení minimálne zvukovo.

  • Ručičky budíkov sa vytočia na maximum a klesnú na minimum - Ak sa tak nestane, nebudeme notifikovaní o prípadnom probléme, napr. nebudeme vedieť o prázdnej nádrži alebo o prehriatí chladiacej kvapaliny.

• (slide) Ak teda dôjde k nejakému problému počas prevádzky, budeme naň včas upozornení.

• (slide) Údaje o stave zariadení môžeme aj zbierať a následne ich vyhodnocovať. Tým budeme robiť diagnostiku zariadení. Samotná diagnostika je proces, ktorým sa analyzujú údaje zo zariadenia s cieľom zistiť, či nie sú v systéme chyby alebo odchýlky.

• Diagnostiku môžeme vykonávať:

  • na základe historických dát - porovnávame aktuálny stav zariadenia s predchádzajúcimi dátami
  • analýzou chýb - ak dôjde k zlyhaniu zariadenia, v rámci diagnostiky sa analyzujú dostupné dáta, aby sa zistila príčina problému
  • prevencia porúch - tu sa využíva prediktívna analýza, ktorá dokáže predpovedať potenciálny vznik chyby ešte predtým, ako k nej dôjde len na základe aktuálneho stavu zariadenia (a analyzovaných historických dátach)

• (slide)

  1. Zvýšená spoľahlivosť - Zariadenia môžu automaticky identifikovať a prípadne aj opraviť vzniknuté chyby (napr. nesprávny formát konfigurácie, zaplnená FLASH pamäť a pod.).

  2. Údržba a prevencia - Včasnou diagnostikou sa znižuje potreba nákladných opráv a výpadkov, pretože sa problém vyrieši ešte predtým, ako k nemu naozaj dôjde. Tým je možné predísť vážnym materiálnym (napr. chyba požiarneho senzora), finančným alebo v najhoršom prípade škodám na zdraví človeka (napr. zlyhanie inzulínovej pumpy alebo holdera na srdci).

  3. Zníženie prestojov - Neustále monotirovanie znamená, že potenciálne problémy sú identifikované a odstránené rýchlo.

Problém vo výučbe a riešeniach

• Problémom je, že sa diagnostike málokedy venujeme aj vo výučbe, čím sme častokrát odkázaný na riešenia typu “hop-trop” (ide-nejde, trial-and-error). Ak týmto spôsobom budeme pristupovať aj v produkcii, s veľkou pravdepodobnosťou sa nám budú produkty vracať v momente, keď z nejakého dôvodu prestanú u zákazníka fungovať. A pritom môže ísť o jednoduchý problém, ktorý dokáže vyriešiť aj sám zákazník (napr. došli baterky, nedá sa pripojiť na sieť alebo nedarí sa odoslať dáta z dôvodu nesprávnych nastavení, a pod.)

Príklady

• senzor fyzikálnej veličiny - odčítanú hodnotu porovnať s prípustným rozsahom uvedeným v datasheet-e od výrobcu
• motorčeky - rozkrútiť a vypnúť
• LED svetlo - v kombinácii so snímačom osvetlenia - ak svieti, tak snímač osvetlenia musí odčítať adekvátnu hodnotu, ak nesvieti, tak podobne.
• batéria - monitorovanie stavu batérie a signalizácia, ak je jej úroveň nízka
• voľné miesto - kontrola dostatočného voľného miesta na FLASH disku
• súčasťou self-testu môže byť aj automatická kalibrácia

Úvod do komunikácie

• (slide) V prvej prednáške sme hovorili o architektúre IoT, kde sme si ukázali, ako svet IoT funguje v 4. vrstvách. Dnes sa však budeme rozprávať o komunikácii vo svete IoT, čo je téma charakteristická pre komunikáciu medzi zariadeniami prvej a druhej vrstvy - medzi vecami a IoT bránami. Zvyšné vrstvy sú totiž prepojené vysokorýchlostným internetom, takže tam to už nie je žiadna výzva, pretože na prenos využívajú komunikačné protokoly aplikačnej vrstvy OSI/ISO modelu.

  

Machine to Machine (M2M)

• (slide) Ak by sme mali začať hovoriť o komunikácii vecí v IoT, mali by sme začať s termínom M2M.

• (slide) V skratke by sme M2M komunikáciu mohli charakterizovať ako priamu komunikáciu medzi dvoma zariadeniami pomocou akéhokoľvek komunikačného kanála bez nutnosti manuálnej ľudskej asistencie.

• Hlavným účelom M2M komunikácie vo svete IoT je prenos dát od vecí (koncových zariadení) smerom do internetu. V tom prípade je jedným komunikujúcim zariadením samotný chytrý senzor a druhým komunikujúcim zariadením je počítačový systém, ktorý obyčajne tieto údaje posiela ďalej v rámci IoT architektúry.

• Dá sa povedať, že M2M reprezentuje architektúru, kde nie je dôležité, aká technológia je použitá na prenos, prípadne pomocou akého komunikačného protokolu sú tieto údaje prenášané.

Rozdiel medzi M2M a IoT

• (slide) Dá sa stretnúť s interpretáciou, že M2M je vlastne IoT. Ale to nie je pravda - M2M hovorí obecne o prepojení dvoch ľubovoľných zariadení ľubovoľným spôsobom. Takže správna interpretácia by mala byť, že IoT pre svoju činnosť potrebuje M2M, ale M2M nepotrebuje IoT.

  

Communication Technologies

• Nás však bude a musí zaujímať, aké technológie sú použité na prenos údajov (do internetu). Ich výber je samozrejme ovplyvnený viacerými faktormi:

  • cenou,
  • dosahom,
  • množstvom prenášaných dát, alebo
  • spotrebou.

• Poďme sa teda pozrieť na niektoré technológie populárne v IoT bližšie.

Power Consumption

• (slide) Jedným z dôležitých aspektov výberu komunikačnej technológie je jej spotreba. Treba si totiž uvedomiť, že častým riešením a nasadením IoT je v prostredí, kde nie je trvalý prívod elektrickej energie. Spotreba celého zariadenia (veci) teda predstavuje jeden z kľúčovch faktorov pri jeho dizajnovaní a návrhu.

  

Communication Distance

• (slide) Ďalším nemenej dôležitým aspektom výberu správnej komunikačnej technológie je jej dosah. Tu sa je možné odraziť od charakteristiky siete, v ktorej bude riešenie nasadené:

  • PAN (Personal Area Network)
  • LAN (Local Area Network)
  • MAN (Metropolitan Area Network)
  • WAN (Wide Area Network)
  • LPWAN (Low-Power Wide Area Network)

  

• (slide) Zjednodušene sa proste môžeme na dosah takto:

  • short range (< 10m) - nositeľná elektronika (PAN)
  • local area (< 100m) - domácnosť (LAN)
  • wide area (km) - celý zvyšok sveta (MAN, WAN, LPWAN)

  

Data Rate

• V závislosti od charakteristiky prenášaných údajov nás môže zaujímať aj otázka max. množstva prenášaných dát. V tejto kategórii samozrejme dominujú technológie pre prenos dát v LAN sieťach (WiFi) a vo WAN sieťach (LTE, 2G, 3G, 4G).

Communication Protocols

• (slide) V prípade technológií komunikujúcich v prostredí IP sietí nás bude zaujímať aj výber komunikačného protokolu, pomocou ktorého budú veci komunikovať buď so zariadeniami vyšších vrstviet (napr. posielať údaje zo senzorov) alebo medzi sebou navzájom.

  

• Ako je možné vidieť, tak tieto protokoly pracujú na aplikačnej vrstve ISO/OSI modelu. Medzi tie najznámejšie a najpopulárnejšie protokoly patria:

  • HTTP
  • MQTT
  • CoAP
  • XMPP
  • LwM2M

• (slide) My sa budeme venovať konkrétne len protokolom HTTP a MQTT.

  

MQTT Protokol

• (slide)

• Komunikačný protokol MQTT patrí medzi najčastejšie používané komunikačné protokoly vo svete IoT. Je veľmi jednoduchý binárny protokol, ktorý sa vyznačuje malou veľkosťou prenášaných paketov, napr. v porovnaní s protokolom HTTP. Rovnako je protokol veľmi jednoducho implementovateľný na strane klienta. Pri jeho vývoji bol kladený veľký dôraz na jednoduchosť použitia, vďaka čomu sa hodí aj na zariadenia s obmedzenými zdrojmi, akými sú napríklad mikorkontroléry. [MQTT 3.1.1 specification]

Vznik protokolu

The MQTT protocol was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link). They needed a protocol for minimal battery loss and minimal bandwidth to connect with oil pipelines via satellite. The two inventors specified several requirements for the future protocol:

• Simple implementation
• Quality of Service data delivery
• Lightweight and bandwidth efficient
• Data agnostic
• Continuous session awareness

These goals are still at the core of MQTT. However, the primary focus of the protocol has changed from proprietary embedded systems to open Internet of Things (IoT) use cases. This shift in focus has created a lot of confusion about what the acronym MQTT stands for. The short answer is that MQTT is no longer considered an acronym. MQTT is simply the name of the protocol.

Návrhový vzor Publish-Subscribe

• The publish/subscribe pattern (also known as pub/sub) provides an alternative to a traditional client-server architecture. In the client-server model, a client communicates directly with an endpoint. The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists. The connection between them is handled by a third component (the broker). The job of the broker is to filter all incoming messages and distribute them correctly to subscribers.

  

Poslanie správy

• Posielať správy je možné okamžite, ako sa klient pripojí k broker-ovi. Každá správa musí obsahovať

  • tému (z angl. topic), vďaka ktorej bude broker vedieť správu poslať všetkým zainteresovaným klientom, a ** údaje (z angl. payload), ktoré reprezentujú samotné prenášané údaje.

• Pri posielaní je možné okrem témy a samotných údajov pridať aj niekoľko ďalších atribútov. Pozrieme sa na ne podrobnejšie:

  • topic name

    • pravidla pre topiky

  • retain flag

  • payload

  • packet id

  • qos

    • At most once (QoS 0)
    • At least once (QoS 1)
    • Exactly once (QoS 2)

  • DUP flag

Ako organizovať témy

Wildcards

Témy začínajúce znakom $

Posledná vôľa

• This message notifies other clients when a client disconnects ungracefully.

Porovnanie protokolov HTTP a MQTT