Tehnologije s podroˇ cja Interneta Stvari

Posebnost naˇse spletne aplikacije je, za razliko od ˇze obstojeˇcih aplikacij interneta stvari (IoT), da nam mora omogoˇcati pretakanje velikega toka podatkov, ki se ustvarja pri izvajanju meritev dinamike struktur. Za zagotavljanje zanesljivosti prejemanja paketov in poenostavitvijo prikaza ter shranjevanja toka podatkov, smo se osredotoˇcili na ˇze obstojeˇce protokole, ki so zgrajeni na osnovi TCP/IP protokola. Glede na naravo naˇsega problema, smo se odloˇcili za uporabo kombinacije protokolov MQTT (ang.

Message Queuing Telemetry Transport) in WebSocket.

2.2.1.1 MQTT protokol

MQTT je popularen odprtokodni protokol za komunikacijo med napravami (M2M) na podroˇcju IoT. Prvo verzijo protokola sta leta 1999 razvila Andy Stanford-Clark in Arlen Nipper za namen spremljanja stanja naftnih cevi. Javno dostopen in ˇsirˇse uporabljen je postal po letu 2013, ko je bila verzija v3.1 uradno potrjena. Od takrat naprej se protokol aktivno nadgrajuje, razvija in uporablja na ˇstevilnih podroˇcjih interneta stvari. Po podatkih uradne spletne strani specifikacije [8], so najpogostejˇsi primeri uporabe v avtomobilski industriji, logistiki in transportu, nadzorovanju proizvodnih procesov, pametnih domovih, razliˇcnih vejah energetike ter celo v potroˇsniˇskih izdelkih (npr. male vremenske postaje). Z drugimi besedami, po opisu iz knjige [9], reˇsuje tipiˇcne izzive na podroˇcju IoT in M2M aplikacij in tako ponuja:

– enostavno poˇsiljanje podatkov med klienti,

– posredovanje velikega volumna podatkov brez pretiranih zahtev zmogljivosti sistema, – poˇsiljanje majhnih paketov v velikih koliˇcinah,

– moˇzno posluˇsanje dogodkov v primeru spremembe stanja, – podpira vedno-povezan in vˇcasih-povezan model,

– zagotavlja dostavo paketov tudi pri nezanesljivih internetni povezavi, – omogoˇca komunikacijo zelo blizu realnega ˇcasa (ang. real-time delivery), – ponuja varnost in zasebnost,

– zelo skalabilen in omogoˇca distribucijo podatkov med veˇc tisoˇc klienti.

V tem teoretiˇcnem delu bodo predstavljene osnovne funkcije in princip delovanja proto-kola, ki jih programer potrebuje za razumevanje in razvoj aplikacij in so delno povzete po knjigi [9]. Podrobnejˇse specifikacije pa so dostopne v uradnem standardu izdanemu s strani neprofitne organizacije OASIS [10].

MQTT deluje po sistemu objavi-naroˇci (ang. publish/subscribe). Pri tovrstnem sis-temu so na eni strani odjemalci oz. klienti (ang. client), med njimi pa posrednik (ang. broker). Klienti so zaloˇzniki (ang. Publisher) ali naroˇcniki (ang. Subscriber).

Zaloˇzniki pod doloˇceno temo (ang. topic) objavljajo podatke in jih posredujejo posre-dniku, naroˇcniki pa se na to temo prijavijo in podatke prejemajo preko posrednika. Za enostavnejˇso predstavo sistema si lahko ogledamo shemo 2.3.

Posrednik

Ponekod v literaturi poimenovan tudi MQTT server, je kljuˇcen gradnik MQTT sistema, ki upravlja s sporoˇcili, skrbi za varnost in avtentifikacijo klientov ter zagotavlja, da so

Teoretiˇcne osnove in pregled literature

MQTT posrednik (ang. broker) Založniki

(ang. publishers) Založniki in naročniki

(ang. publishers and subscribers) Naročniki (ang. subscribers)

Objavljanje Naročanje

Slika 2.3: Delovanje MQTT protokola. Klienti so lahko naroˇcniki, zaloˇzniki ali oboje hkrati. [8].

sporoˇcila dostavljena v skladu z doloˇcenim kakovostnim razredom. Ponavadi je posre-dnik nameˇsˇcen na zanesljivem raˇcunalniku, ki obratuje neprestano. Obiˇcajno imamo v sistemu enega posrednika, pri kompleksnejˇsih aplikacijah pa lahko pride tudi do si-tuacije, kjer jih imamo veˇc. V tem primeru je moˇzno posrednika nastaviti, da obratuje kot most (ang. bridge). Tako se torej eden izmed posrednikov do drugega obnaˇsa kot klient. Posrednika je mogoˇce nastaviti tudi tako, da sporoˇcila poˇsilja preko protokola WebSocket. To je ˇse posebej uporabno, kadar ˇzelimo sporoˇcila poˇsiljati direktno v sple-tni brskalnik, ki sam po sebi ne podpira MQTT protokola. V tem primeru se splesple-tni brskalnik poveˇze s posrednikom preko WebSocket protokola in se obnaˇsa kot samosto-jen klient. Za namestitev posrednika je na voljo veˇc ponudnikov. V naˇsem primeru smo izbrali odprtokodnega posrednika Eclipse Mosquitto [11], ki je redno vzdrˇzevan in podprt s strani ˇstevilnih organizacij. Za testne namene in razhroˇsˇcevanje pa je na voljo tudi javno dostopen posrednik v oblaku [12].

Klient

Vsaka naprava ali aplikacija, ki se poveˇze s posrednikom in preko njega objavlja sporoˇcila (opravlja funkcijo zaloˇznika) ali se na njih le naroˇci (opravlja funkcijo naroˇcnika).

Klient je lahko tudi naroˇcnik in zaloˇznik hkrati. Klienti so tako lahko samostojni raˇcunalniki, mobilne naprave, mikrokrmilniki ali spletne aplikacije. Tudi tu je na voljo vrsta knjiˇzic za razvoj klienta v razliˇcnih programskih jezikih. Ker bomo v naˇsem pri-meru uporabljali programski jezik Python in zaradi specifiˇcne narave naˇse aplikacije (velik tok podatkov), smo izbrali knjiˇzico asyncio-mqtt [13], ki za osnovo uporablja priznano knjiˇzico Eclipse Paho [14].

8

Teoretiˇcne osnove in pregled literature Potek prijave in objave v temo

Vsak klient najprej izvede povezavo s posrednikom. Zaradi varnosti, se na podlagi posredovanega uporabniˇskega imena in gesla, ki smo ga predhodno izbrali med kon-figuracijo posrednika, opravi overitev klienta. Po uspeˇsno vzpostavljeni povezavi po-srednik drˇzi odprto povezavo s klientom, dokler je ta ne izgubi ali poˇslje kontrolni paket za zaprtje le-te. Klient se nato prijavi (ang. subscribe) na izbrano temo (ang.

topic). Teme imajo hierarhiˇcno strukturo, kjer so (/) uporabljene kot loˇcila stopenj teme. Primer bi torej bil: meritve/raspberry01/vhod01, kjer je meritve najviˇsja stopnja teme, vhod01 pa najniˇzja. Pri prijavah sta nam na voljo tudi dva nadome-stna znaka (ang. wildcards), ki poenostavita proces v primeru, da se ˇzelimo naroˇciti na veˇc tem hkrati. Plus znak (+) je enostopenjski nadomestni simbol, ki nadomesti katerokoli ime na specifiˇcni stopnji. Naroˇcilo na meritve/+/vhod01 bo tako rezul-tiralo kot naroˇcilo na vse raˇcunalnike RPI npr. meritve/raspberry01/vhod01 in meritve/raspberry02/vhod01. Drugi nadomestni znak je simbol kljuˇcnika (#), ki je veˇcstopenjski in se ga lahko uporablja le na koncu filtra teme. V tem primeru bomo naroˇceni na vse teme, katerih najviˇsja stopnja je enaka. Naroˇcilo na meritve/# torej pomeni naroˇcilo na vse teme, ki se zaˇcnejo zmeritve/. Pozorni moramo biti tudi na velike in male ˇcrke.

Kakovostni razredi

Protokol MQTT nam omogoˇca definicijo kakovosti storitve (ang. Quality of Service).

Na tem mestu je vredno omeniti, da definicija kakovostnega razreda vkljuˇcuje tako po-srednika kot klienta. Torej lahko objavljamo z neko stopnjo kakovosti in se prijavljamo (z drugim klientom) z drugaˇcno stopnjo kakovosti. V tem primeru bo posrednik prilago-dil kakovost storitve na niˇzjo zahtevano. Z izbrano stopnjo kakovosti meritve vplivamo, na kakˇsen naˇcin se preverja, ˇce je bilo sporoˇcilo uspeˇsno dostavljeno. Obstajajo sledeˇci kakovostni razredi:

– 0, dostavljeno najveˇc enkrat: Ta kakovostni razred ponuja enako garancijo kot osnovni TCP protokol na osnovi katerega je MQTT zgrajen. Sporoˇcilo ni potrjeno s strani prejemnika ali destinacije. Poˇsiljatelj le poˇslje sporoˇcilo. Sporoˇcila, ki ne prispejo na cilj so izgubljena. Glavna prednost te stopnje je, da porablja najmanj raˇcunalniˇskih virov in internetne pasovne ˇsirine.

– 1, dostavljeno vsaj enkrat: Ta kakovostni razredu doda potrditvene zahteve na strani prejemnika. Poˇsiljatelj shranjuje sporoˇcilo, dokler ne dobi potrdila, da je bilo sporoˇcilo prejeto s strani prejemnika. Zagotovi, da je bilo sporoˇcilo dostavljeno. ˇCe potrdila v specifiˇcnem ˇcasu ne prejme, le-tega poˇslje ponovno. Zavedati se moramo, da v doloˇcenih primerih lahko pride do podvojenih sporoˇcil, ki jih moramo v pro-gramu odstranjevati sami. Ta kakovostni razred tudi porabi precej veˇc raˇcunalniˇskih virov in internetne pasovne ˇsirine.

– 2, dostavljeno toˇcno enkrat: Zadnji in najstroˇzji kakovostni razred storitve zago-tavlja, da je sporoˇcilo vedno dostavljeno le enkrat. Zahteva dodaten tok informacij, ki ˇse dodatno potrdi, da je bilo sporoˇcilo prejeto s strani prejemnika natanko enkrat.

Je najbolj zahteven, kar se tiˇce virov in pasovne ˇsirine. Ponavadi se ga uporablja le v primerih, kjer nimamo stabilne internetne povezave in ˇzelimo zagotoviti, da bo sporoˇcilo kljub temu dostavljeno, ˇceprav z nekolikˇsnim zamikom.

Teoretiˇcne osnove in pregled literature 2.2.1.2 WebSocket protokol

WebSocket protokol je uradno definiran in podrobneje opisan v internetnem standardu RFC 6455 [15], ki je bil sprejet leta 2011, ko je veˇcina internetnih brskalnikov ˇze uradno podpirala protokol. V pomoˇc pri razumevanju in programiranju nam je bila knjiga av-torja A. Lombardi [16], uradna mozillina dokumentacija za razvijalce 17 in dokumen-tacija Python knjiˇzice websocket [18]. Tehnologija Websocket omogoˇca dvosmerno komunikacijo oziroma polni dupleks (ang. full-duplex), komunikacijski kanal, preko enojne TCP povezave. Tehnologija daje moˇznost izdelave aplikacije, katere stanja se posodabljajo zelo blizu realnega ˇcasa, brez ponovnega nalaganja spletne strani. ˇCeprav WebSocket uporablja HTTP kot zaˇcetni transportni mehanizem, se komunikacija med odjemalcem in streˇznikom ne konˇca, temveˇc ostane odprta. Protokol se tako mnoˇziˇcno uporablja za implementacijo klepetalnic, iger za veˇc igralcev, IoT platform, finanˇcnih aplikacij, beleˇzenj aktivnosti uporabnikov, GPS aplikacij, izobraˇzevalnih platform ...

Skratka tam, kjer v spletni aplikaciji potrebujemo osveˇzevanje v realnem ˇcasu. Na slikah 2.4 in 2.5 sta prikazana diagrama, ki prikazujeta princip delovanja klasiˇcnega HTTP v primerjavi z WebSocket protokolom.

Zahtevek

Klient Strežnik

Odgovor

Povezava zaprta

Slika 2.4: ˇZivljenjski cikel HTTP protokola [19].

Standardni HTTP protokol poteka v ˇstirih korakih. Najprej se odpre TCP povezava med odjemalcem in streˇznikom. Nato odjemalec poˇslje zahtevek (ang. request) in prejme odgovor streˇznika (ang. response) oziroma zahtevane podatke. V konˇcnem koraku se povezava zapre ali ponovno uporabi za nadaljnje zahteve.

Za razliko od HTTP, WebSocket protokol ne operira v ciklu zahtevek-odgovor. Tu se najprej preko HTTP protokola zgodi spoznavanje (ang. handshake) med streˇznikom in odjemalcem. Takrat tudi streˇznik prejme sporoˇcilo, da bo za komunikacijo uporabljen WebSocket in ne HTTP protokol. Tunel (ang. network tunnel) za dvosmerno komuni-kacijo nato ostane odprt in podatki med streˇznikom in odjemalcem tako lahko prosto prehajajo v realnem ˇcasu, dokler eden izmed njih ne zapre povezave.

10

Teoretiˇcne osnove in pregled literature

Klient Strežnik

Spoznavanje (HTTP)

Dvosmerna komunikacija (WebSocket)

Ena izmed strani zapre povezavo

Povezava se odpre

Dolgotrajna povezava

Povezava zaprta

Slika 2.5: ˇZivljenjski cikel WebSocket protokola [17].