SVEUCILIŠTE U ZAGREBUFAKULTET ELEKTROTEHNIKE I RACUNARSTVA

DIPLOMSKI RAD br. 1299

Usporedba protokola MQTT iCoAP na uredajima Arduino

Randy Cupic

Zagreb, lipanj 2016.

iii

SADRŽAJ

1. Uvod 1

2. Protokol MQTT 32.1. Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Objavi-pretplati obrazac . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1. Filtriranje poruka . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2. Prednosti i nedostatci . . . . . . . . . . . . . . . . . . . . . . 5

2.3. Princip rada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1. Posrednik (broker) . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2. Jedinstveni identifikator resursa (URI) . . . . . . . . . . . . . 8

2.3.3. Teme i pretplate . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.4. Kvaliteta usluge (QoS) . . . . . . . . . . . . . . . . . . . . . 10

2.3.5. Zadržavanje poruka . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.6. Posljednja želja . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.7. Cista sjednica . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. Format poruke u protokolu MQTT . . . . . . . . . . . . . . . . . . . 11

2.4.1. Fiksno zaglavlje . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.2. Varijabilno zaglavlje . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3. Sadržaj poruke . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5. Sigurnost u protokolu MQTT . . . . . . . . . . . . . . . . . . . . . . 14

2.6. Protokol MQTT za senzorske mreže (MQTT-S) . . . . . . . . . . . . 15

3. Protokol CoAP 173.1. Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Znacajke protokola CoAP . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3. Usporedba protokola CoAP i HTTP . . . . . . . . . . . . . . . . . . 18

3.4. Strukturni model protokola CoAP . . . . . . . . . . . . . . . . . . . 20

3.4.1. Sloj poruka . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

iv

3.4.2. Sloj zahtjeva i odgovora . . . . . . . . . . . . . . . . . . . . 21

3.5. Format poruke u protokolu CoAP . . . . . . . . . . . . . . . . . . . 23

3.5.1. Zaglavlje poruke . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.2. Token u poruci . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.3. Opcije u poruci . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.4. Sadržaj poruke (Payload) . . . . . . . . . . . . . . . . . . . . 29

3.6. Sigurnost u protokolu CoAP . . . . . . . . . . . . . . . . . . . . . . 29

3.7. Princip rada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.7.1. Pretplata na promjenu stanja . . . . . . . . . . . . . . . . . . 32

3.7.2. Otkrivanje dostupnih resursa . . . . . . . . . . . . . . . . . . 33

4. Uredaji Arduino 344.1. O Arduino platformi . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2. Razvojne ploce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1. Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.2. Arduino Uno R3 . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3. Arduino štitovi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1. Štit za bežicno povezivanje na mrežu (Wi-Fi) . . . . . . . . . 39

4.4. Programiranje Arduino uredaja . . . . . . . . . . . . . . . . . . . . . 40

4.4.1. Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.2. Jednostavan primjer Arduino programa . . . . . . . . . . . . 43

5. Implementacija na uredaju Arduino 445.1. Implementacija protokola MQTT . . . . . . . . . . . . . . . . . . . . 44

5.1.1. Mosquitto posrednik . . . . . . . . . . . . . . . . . . . . . . 44

5.1.2. Programska knjižnica PubSubClient za protokol MQTT . . . 45

5.1.3. Aplikacija Mosquitto za operacijski sustav Linux . . . . . . . 48

5.2. Implementacija protokola CoAP . . . . . . . . . . . . . . . . . . . . 49

5.2.1. Programska knjižnica CoAP Arduino . . . . . . . . . . . . . 49

5.2.2. Racunalna aplikacija za komunikaciju putem protokola CoAP 51

5.3. Korišteni hardver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.1. Senzor za temperaturu i vlažnost zraka . . . . . . . . . . . . 52

5.3.2. Shema povezivanja . . . . . . . . . . . . . . . . . . . . . . . 53

5.4. Prikaz rada testne aplikacije . . . . . . . . . . . . . . . . . . . . . . 54

5.4.1. Komunikacija putem protokola MQTT . . . . . . . . . . . . 55

5.4.2. Komunikacija putem protokola CoAP . . . . . . . . . . . . . 57

v

5.5. Analiza implementacije protokola . . . . . . . . . . . . . . . . . . . 57

5.5.1. Odabir programskih knjižnica . . . . . . . . . . . . . . . . . 59

5.5.2. Analiza zahtjeva na resurse . . . . . . . . . . . . . . . . . . . 59

5.5.3. Velicina poruke . . . . . . . . . . . . . . . . . . . . . . . . . 60

6. Zakljucak 61

Literatura 62

vi

1. Uvod

U današnje vrijeme sve je više fizickih objekata, poput raznih uredaja, vozila i

raznih ostalih predmeta, koji sadrže hardver, softver i razne senzore te su povezani

na mrežu, što im omogucuje razmijenu podataka. Takva mreža povezanih objekata

naziva se Internet Stvari (eng. Internet of Things). Neki od primjera takvih objekata su

pametni mobilni uredaji, pametni satovi, pametni automobili i mnogi drugi. A jedna

od zanimljivih primjena su svakako pametni gradovi, gdje se koristi mreža senzora,

rasporedenih diljem grada, koja prikuplja podatke, kao što su temperatura, kvaliteta

zraka, razina buke, gustoca prometna te mnogi drugi parametri. Prikupljeni podaci se

obraduju i koriste za pružanje informacija korisnicima, kao što je primjerice planiranje

rute kretanja na temelju gustoce prometa ili kvalitete zraka.

Svaki objekt u sklopu mreže je jedinstveno identificiran na temelju ugradenog ra-

cunalnog sustava, i u mogucnosti je služiti se postojecom mrežnom infrastrukturom,

znanom kao Internet. Medutim, uredaji u mreži mogu biti vidno razliciti po ugrade-

nom hardveru i softveru. Primjerice, uredaji koji pomocu senzora prikupljaju podatke

i šalju ih dalje na obradu, ne trebaju hardver velikih performansa. Jedan od primjera

uredaja prigodnih za takvu svrhu je uredaj Arduino, koji je obraden u ovom radu. Nje-

gov hardver je daleko slabiji od hardvera prosjecnog osobnog racunala. I zbog toga je

važno posvetiti pažnju optimizaciji i minimalizaciji kod projektiranja sustava, kako bi

se smanjili zahtjevi na hardver, ali i primjerice potrošnja elektricne energije, mrežnog

prometa i drugo.

Jedna od najvažnijih stavki kod takvih sustava je komunikacija, odnosno razmjena

poruka medu sustavima. Upravo je to podrucje kojim se bavi ovaj rad. U sklopu

ovog rada su opisani protokoli MQTT i CoAP, koji se koriste za razmjenu poruka.

Glavna karakteristika ovih protokola je to što su namjenjeni upravo za korištenje kod

sustava gdje je bitno minimizirati mrežni promet i zahtjeve na hardver, te za rad u

uvjetima gdje je veza nestabilna i gdje je mogucnost gubitka poruke velika. Protokol

MQTT koristi princip objavi-pretplati, uz slanje poruka putem mrežnog sloja TCP, dok

protokol CoAP koristi REST nacela te šalje poruke putem mrežnog sloja UDP.

1

U ovom radu su opisana oba protokola, te je u drugom dijelu rada, na primjeru

jednostavnog sustava koristeci uredaj Arduino, prikazana njihova implementacija u

praksi. Pritom je pažnja posvecena performansama uz usporedbu oba protokola.

Slika 1.1: Prikaz sheme Interneta stvari

2

2. Protokol MQTT

2.1. Uvod

MQTT (eng. Message Queuing Telemetry Transport), poznat i po svom starom

imenu MQ Integrator SCADA Device Protocol je pojednostavljeni protokol za komu-

nikaciju izmedu uredaja, baziran na principu objavi-pretplati, koji koristi mrežni pro-

tokol TCP/IP. Osmišljen je da bude otvoren, lagan i jednostavan za implementaciju,

odnosno da se može koristiti u ogranicenim okruženjima s ogranicenim mogucnos-

tima procesiranja, malim kapacitetom memorije (programske i radne) te velikim kaš-

njenjima. Kao takav, smanjuje zahtjeve na propusnost mreže te predstavlja prihvatljivo

rješenje za korištenje u sustavima s nestabilnom mrežnom vezom, gdje prevladavaju

male brzine prijenosa i gdje postoji velika mogucnost za gubitak informacija. Protokol

je nastao krajem 1990-ih, odnosno pocetkom 2000-ih godina, a inicijalno je razvijen

od strane tvrtke IBM, no danas je to otvoreni protokol. Iako se u nazivu poruka nalazi

red cekanja (eng. message queuing), sam red poruka ne mora nužno biti podržan kao

standardna znacajka u svim situacijama.

Pri osmišljavanju protokola, dizajneri su se vodili odredenim nacelima te napravili

odredene odluke, što je utjecalo na nacin kako protokol danas funkcionira. Neka od

nacela navedena su u nastavku:

1. Zadržavanje jednostavnosti protokola, bez dodavanja velikog broja najcešce ne-

potrebnih znacajki, kako bi se dobila jedna zaokružena cjelina koja se jednos-

tavno može implementirati i integrirati u postojeca rješenja.

2. Primjena obrasca objavi-pretplati, koji je prikladan za vecinu senzorskih sustava,

te koji omogucuje uredajima da se prijave i objave stvari koje do tada nisu bile

poznate.

3. Svodenje potrebe za administracijom na nulu, ili što bliže tome, uz prikladne

reakcije na neocekivane akcije, kako bi se omogucilo aplikacijama da jednos-

3

tavno funkcioniraju, primjerice, da mogu po potrebi dinamicki kreirati teme za

pretplatu.

4. Minimiziranje velicine poruke, tako da se maksimalno pojednostavi zaglavlje,

odnosno da se dodaju samo najpotrebnije informacije. Cilj je da protokol bude

što ucinkovitiji po pitanju protocnosti mreže.

5. Mogucnost rada u okruženjima s cestim gubitcima veze i paketa, kod niske pro-

pusnosti mreže i visokog kašnjenja. Primjer su sustavi na mjestima gdje je teško

i skupo dovesti stabilnu i brzu mrežu.

6. Kontinuirano održavanje veze.

7. Podrška za klijente sa slabim mogucnostima obrade i malim kapacitetom memo-

rije.

8. Omogucavanje postavljanja kvalitete usluge za pojedine poruke, gdje to okruže-

nje dozvoljava.

9. Fleksibilnost oblika sadržaja, bez da se inzistira na odredenim fiksnim oblicima.

2.2. Objavi-pretplati obrazac

Objavi-pretplati (eng. publish-subscribe) je obrazac za razmjenu poruka, u kojem

pošiljatelji poruka, koji se nazivaju objavljivaci (eng. publishers), ne šalju svoje po-

ruke unaprijed poznatom primatelju poruke, vec ih smještaju u klase, koristeci teme.

Na taj nacin objavljivaci ne znaju tko ce sve primiti poruku. Pretplatnici (eng. subscri-

bers) se pretplacuju na teme (eng. topic) koje ih zanimaju, te primaju sve one poruke

koje razni objavljivaci objavljuju na tu temu. Nacelo rada je prikazano na slici 2.1.

Pretecom ovog obrasca se smatra sustav za novosti, pod imenom Isis Toolkit, opisan

1987. godine.

2.2.1. Filtriranje poruka

Poruke koje objavljivaci objave, potrebno je filtrirati kako bi se poslale odgova-

rajucim pretplatnicima. Svaki pretplatnik prima odredeni podskup poruka, za koje je

zainteresiran. Za to je zadužen treci posrednik, koji se naziva broker. Pretplatnici se

registriraju na brokera i specificiraju na koje se teme žele pretplatiti, a broker zatim

sprema poruke koje primi od objavljivaca i prosljeduje ih registriranim pretplatnicima

4

Slika 2.1: Prikaz nacela obrasca objavi-pretplati

koji su pretplaceni na tu temu (eng. store and forward). Dodatno, broker može posta-

viti prioritete poruka u redu poruka, prije nego ih proslijedi dalje.

Postoje dva oblika filtriranja:

– Bazirano na temi (eng. topic-based) - poruke se objavljuju u tzv. teme (eng.

topics), koje se još nazivaju i logicki kanali. Svi pretplatnici na neku temu ce

primiti iste poruke koje su objavljene u toj temi. Odgovornost za definiranje

klasa poruka na koje se pretplatnici mogu pretplatiti pripada objavljivacu.

– Bazirano na sadržaju (eng. content-based) - pretplatnik definira ogranicenja

na sadržaj poruke i atribute, koja moraju biti zadovoljena da bi ta poruka bila

njemu proslijedena.

Moguce su i hibridne konfiguracije dvaju navedenih oblika, gdje se pretplatnici pret-

placuju na odredene teme, te postavljaju ogranicenja na sadržaj poruka iz tih tema.

2.2.2. Prednosti i nedostatci

Objavi-pretplati obrazac za prijenos poruka ima odredene prednosti i nedostatke,

naspram ostalih oblika prijenosa, kao što je primjerice tradicionalno korišteni klijent-

poslužitelj (eng. client-server) obrazac. Najvažnije znacajke navedene su u nastavku.

Slaba sprega i visoka skalabilnost

Slaba sprega (eng. loose coupling) postignuta je zahvaljujuci cinjenici da objav-

ljivaci i pretplatnici nisu izravno vezani i ne moraju znati jedan za drugog, vec je u

fokusu tema. Na taj nacin svaki sudionik (objavljivac ili pretplatnik) može normalno

nastaviti s radom, bez obzira na ostale, za razliku od tradicionalnog klijent-poslužitelj

pristupa, gdje procesi na obije strane moraju biti pokrenuti i gdje moraju znati jedan

za drugog.

5

Štoviše, ovakav nacin komunikacije pruža vecu skalabilnost (eng. scalability) nego

kod tradicionalnog klijent-poslužitelj pristupa, zahvaljujuci raznim tehnikama, kao što

su paralelna obrada, pohranjivanje poruka u predmemoriju (eng. caching), usmjerava-

nje temeljeno na stablu ili mreži, te mnoge druge.

Nefleksibilno semanticko razdvajanje

Struktura podataka koji se objavljuju mora biti dobro definirana, što predstavlja

problem za fleksibilnost, jer se kod izmjene te strukture treba znati za sve objavljivace,

te je potrebno napraviti izmjene na istima, ili na neki nacin održati kompatibilnost sa

starijim verzijama. Medutim, rijec je o problemu zajednickom svim klijent-poslužitelj

arhitekturama. S obzirom na to da se zahtjevi s vremenom mijenjaju, nefleksibilnost

strukture podataka može predstavljati veliki problem za programere. Najbolji nacin za

se nositi s tim problemom je verzioniranje sadržaja te izmjena URL-a zbog kompati-

bilnosti sa starijim verzijama.

Poteškoce kod prijenosa poruka

Kod ovakvog dizajna, postavlja se pitanje pouzdanosti razmjene poruka. S obzirom

na to da objavljivac ne zna za pretplatnike, on šalje poruke u odredene teme i zapravo

ne zna da li je ta poruka stigla do pretplatnika. On može racunati s time da pretplatnik

sluša, dok je zapravo došlo do problema tako što je pukla veza, poruka je izgubljena

ili je pretplatnik otkazao pretplatu. Jedan od primjera je održavanje zapisa o greškama

(eng. error logging). Ukoliko dode do greške na pretplatniku koji je zadužen za pri-

manje i zapisivanje takvih grešaka, kad neki objavljivac dojavi grešku, nema loggera

da to zapiše i prijavi grešku. Moguce rješenje je korištenje više paralelnih pretplatnika

koji ce bilježiti greške. Kod klijent-poslužitelj pristupa, sustav ce biti obaviješten da je

došlo do greške u serveru za održavanje zapisa o greškama, ali se mora znati nositi s

tim dogadajem, što komplicira dizajn klijenta i poslužitelja.

Dodatni problemi se mogu javiti kod korištenja brokera kao posrednika. Broker

može biti dizajniran da poslužuje poruke odredeno vrijeme, nakon kojega ce pres-

tati, bez obzira je li poruka stigla do pretplatnika. U slucaju s održavanjem zapisa o

greškama, opet nece biti sustava koji ce zapisati te greške. Ovakav dizajn ne može

garantirati da ce poruka biti sigurno dostavljena do pretplatnika, te je potrebno izvan

ove arhitekture implementirati mehanizme koji ce osigurati prijenos poruke, primjerice

tako da se od pretplatnika traži potvrda o primitku.

6

Problem sa skalabilnošcu

Iako sustavi temeljeni na ovakvom obrascu imaju mnogo bolju skalabilnost nego

sustavi temeljeni na klasicnom klijent-poslužitelj pristupu, i tu se mogu javiti odredeni

problemi pri velikom broju umreženih uredaja. Neki od problema jesu:

– Periodi opterecenja (eng. load surges) - periodi u kojima je mrežna propus-

nost zasicena zahtjevima za pretplate, koje slijede periodi niske propusnosti

– Zastoji (eng. slowdowns) - kod velikog broja aplikacija koje koriste sustav,

može doci do preopterecenja toka poruka prema individualnom pretplatniku

– Zasicenje uslijed emitiranja (eng. IP broadcast storms) - potpuno zasice-

nje lokalne mreže porukama koje guše sav ostali promet, nevezan za objavi-

pretplati arhitekturu

Problem sigurnosti

Kod sustava koji koriste brokera, moguce je prijevarom prisiliti brokera da šalje

odredene poruke krivim pretplatnicima. Takoder je moguce preopteretiti brokere, s

obzirom na to da oni moraju alocirati odredene resurse, buduci da cuvaju zapise o

svim pretplatama. S druge strane, kod sustava bez brokera, pretplatnik bi mogao pri-

miti odredene poruke, za koje nije autoriziran da ih primi. Takoder, neautorizirani

objavljivac bi mogao u sustav objaviti poruke štetnog sadržaja. Problem s neauto-

riziranim klijentima se rješava pomocu enkripcije, koristeci SSL/TLS (eng. Secure

Sockets Layer/Transport Layer Security. Medutim, i dalje ostaje problem autorizira-

nih objavljivaca koji objavljuju poruke štetnog sadržaja. Isti problem postoji i kod

tradicionalnog klijent-poslužitelj pristupa.

2.3. Princip rada

Protokol MQTT koristi prethodno opisani obrazac objavi-pretplati s pojedinim spe-

cificnostima, za razliku od primjerice protokola HTTP, koji koristi obrazac zahtjev-

odgovor. U središtu se nalazi posrednik (broker), na kojeg se spaja mnoštvo klijenata

koji se pretplacuju na odredene teme (eng. topic), koje ih zanimaju. Takoder, klijenti

se mogu povezati na posrednika i kao objavljivaci te objavljivati poruke na odredene

teme, pri cemu ih broker prosljeduje svim klijentima-pretplatnicima koji su pretplaceni

na te teme. Rijec je o principu dogadaja, gdje klijent ne mora zahtijevati informacije

(eng. pull) od poslužitelja, vec mu posrednik dostavlja informacije za koje je zainte-

7

resiran (eng. push), cim se pojavi nešto novo, odnosno cim se dogodi neki dogadaj

(eng. event). Klijent može biti bilo uredaj, koji ima implementiran protokol MQTT,

od malih ogranicenih cvorova u obliku senzorskih sustava s mikrokontrolerom do ve-

likih poslužitelja. Klijent mora znati za brokera, na kojeg se povezuje putem protokola

TCP/IP te, ako je rijec o pretplatniku, mora znati na koju se temu pretplacuje.

2.3.1. Posrednik (broker)

Posrednik (broker) je središnji cvor kod protokola MQTT. Njegova zadaca je da

prima objave od objavljivaca te ih, pomocu tema i filtriranja, prosljeduje zainteresi-

ranim klijentima-pretplatnicima. Svaki klijent mora znati za posrednika, tako da zna

njegovu IP adresu i port, te ostvaruje trajnu vezu s posrednikom putem protokola TC-

P/IP, koja traje sve dok klijent ne zatraži prekid veze, ili dok ne dode do slucajnog

prekida. Kod protokola MQTT je veza uvijek jedan-na-jedan, odnosno izmedu jednog

klijenta i posrednika.

Postoje razni implementacije posrednika za protokol MQTT, koje se razlikuju po

nacinu implementacije i implementiranim funkcionalnostima protokola MQTT, dok

neki od njih implementiraju i dodatne funkcionalnosti povrh postojecih. Neki poz-

nati posrednici su Emqttd, ActiveMQ, Apollo, HiveMQ, IBM MessageSight, JoramMQ,

Mosquitto, RabbitMQ, Solace Message Routers te VerneMQ.

2.3.2. Jedinstveni identifikator resursa (URI)

Za povezivanje s poslužiteljem (posrednikom), potrebno je znati njegove podatke,

kao što su shema, IP adresa, port, te po potrebi korisnicko ime i lozinka. Shema koja se

koristi je "mqtt" za komunikaciju bez enkripcije, odnosno "mqtts" za komunikaciju s

enkripcijom, gdje se paket protokola MQTT omata unutar paketa TLS protokola. Osim

sheme, drugi obavezni podatak je IP adresa, ili DNS ime poslužitelja na kojeg se klijent

želi spojiti. U slucaju kada port nije eksplicitno zadan, koristi se predodredeni port za

protokol MQTT; 1883 za "mqtt" shemu, odnosno 8883 za "mqtts" shemu. Ukoliko je

korisnicko ime zadano u URI-u, ono se koristi u CONNECT paketu, koji se šalje odmah

nakon otvaranja veze. U suprotnom, username zastavica u CONNECT paketu ne smije

biti postavljena. Analogno tome, postoji mogucnost i specificiranja lozinke koja se

takoder koristi u CONNECT paketu. U slucaju kad je lozinka zadana, a korisnicko

ime nije, lozinku je svejedno potrebno poslati. Koncept i primjer URI-a se nalaze u

nastavku:

mqtt[s]://[username][:password]@host.domain[:port]

8

mqtt://192.168.214.28:1883

2.3.3. Teme i pretplate

Za usmjeravanje poruka prema klijentima koriste se teme (eng. topics). Svaki

klijent-objavljivac šalje objave u neku temu, dok se klijenti-pretplatnici pretplate na

odredenu temu i dobivaju sve objave koje klijenti šalju u istu. Teme nije potrebno

konfigurirati, vec je dovoljno slati objave na neku temu. Ako ona do tada nije posto-

jala, kreira se nakon slanja objave u nju. Rijec je o jednostavnom nizu znakova (eng.

string), koji može sadržavati više hijerarhijskih razina odvojenih znakom "/". Primjer

su senzori koji se nalaze u raznim prostorijama unutar kuce, kao i izvan kuci. Klijent

se može primjerice pretplatiti na senzore kao što su:

/kuca/dnevni-boravak/temperatura

/kuca/soba/vlaznost

Moguce je i pretplatiti se istovremeno na više tema, koristeci zamjenski znak (eng.

wildcard). Zamjenski znakovi se mogu koristiti iskljucivo kod pretplata, ne i kod

objava. Postoje dva zamjenska znaka:

– + za jednu razinu hijerarhije

– # za više razina hijerarhije

Primjerice, ako se klijent želi pretplatiti na sve temperaturne senzore u kuci, koristit ce

temu:

/kuca/+/temperatura

S druge strane, ako se želi pretplatiti na sve senzore u sobi, može koristiti temu:

/kuca/soba/temperatura

S obzirom na to da je rijec o zamjenskom znaku za jednu razinu hijerarhije, pretplata:

/kuca/+/temperatura

nece ukljuciti sljedecu pretplatu:

/kuca/soba/ormar/temperatura

Za to se koristi zamjenski znak za više razina hijerarhije. Ako se klijent želi pretplatiti

na sve moguce senzore unutar kuce, koristi temu:

/kuca/#

Moguce su i razine tema bez duljine, koje mogu voditi netipicnom ponašanju. Pri-

mjer jedne takve teme je:

9

tema1//tema2

Sljedeca pretplata obuhvatit ce navedenu pretplatu:

tema1/+/tema2

Isto je moguce i na pocetku ili kraju teme pa ce sljedecu temu:

/tema1/tema2/

obuhvatiti sljedece pretplate:

+/tema1/tema2

/tema1/tema2/+

#

2.3.4. Kvaliteta usluge (QoS)

Protokol MQTT ima definirane tri razine kvalitete usluge (eng. QoS - Quality

of Service), koje definiraju koliko ce se klijent ili posrednik potruditi osigurati da je

poruka uspješno primljena. Razine su sljedece:

0. Posrednik ili klijent ce pokušati poslati poruku jednom, bez potvrde

1. Posrednik ili klijent ce pokušati poslati poruku barem jednom, sa zahtijevanjem

potvrde

2. Posrednik ili klijent ce pokušati poslati poruku tocno jednom, koristeci protokol

rukovanja (eng. handshake) u 4 koraka

Poruke mogu biti poslane na nekom od razina kvalitete usluge, te se klijenti mogu

takoder pretplatiti na neku temu na odredenoj razini kvalitete usluge. Pri tome klijent

bira maksimalnu razinu kvalitete usluge koju ce primiti. U slucaju kad je klijent pret-

placen s razinom 0, a poruka je objavljena s razinom 2, klijent ce poruku primiti kao

razinu 2. Ako je na istu temu drugi klijent pretplacen s razinom 2, on ce tu istu poruku

primiti s razinom 2. S druge strane, ako je klijent pretplacen s razinom 2 a poruka je

poslana s razinom 0, klijent ce ju primiti s razinom 0.

2.3.5. Zadržavanje poruka

Klijenti mogu kod slanja objava zatražiti od posrednika da pohrani i sacuva poruke.

Kad se neki klijent prijavi na temu za koju postoje sacuvane poruke, iste ce mu biti

poslane. Medutim, protokol MQTT ne dozvoljava nakupljanje poruka na posredniku

te se pohranjuje samo posljednja poruka, za razliku od reda poruka.

10

2.3.6. Posljednja želja

Kod povezivanja na posrednika, klijent može posrednika obavijestiti da ima testa-

ment (eng. will). Rijec je o poruci koju ce posrednik poslati, ako se klijent odspoji.

Takva poruka, kao i svaka druga, posjeduje temu i razinu kvalitete usluge. Ovaj je

mehanizam za obavještavanje pretplatnika da se klijent odspojio.

2.3.7. Cista sjednica

Kod povezivanja na posrednika, klijent može postaviti zastavicu za cistu sjednicu

(eng. clean session flag), koja se još naziva i zastavicom za cisti start (eng. clean

start). Ako ta zastavica nije postavljena, veza se tretira kao trajna. U tom slucaju, kad

se klijent odspoji, sve pretplate koje je imao ce ostati te ce sve poruke razine kvalitete

1 ili 2 biti spremljene sve dok se klijent ponovno ne spoji. U slucaju da je zastavica

postavljena, tada ce sve pretplate biti obrisane kad se klijent odspoji.

2.4. Format poruke u protokolu MQTT

Komunikacija u protokolu MQTT funkcionira pomocu razmjene MQTT kontrolnih

paketa. Svaki MQTT kontrolni paket se sastoji od tri dijela, uvijek u tom redoslijedu:

1. Fiksno zaglavlje, prisutno u svim MQTT kontrolnim paketima

2. Varijabilno zaglavlje, prisutno samo u nekim MQTT kontrolnim paketima

3. Sadržaj (eng. payload), prisutan samo u nekim MQTT kontrolnim paketima

2.4.1. Fiksno zaglavlje

U svakom MQTT kontrolnom paketu nalazi se fiksno zaglavlje, velicine 2 bajta,

koje sadrži tri polja: tip MQTT kontrolnog paketa, polje sa zastavicama specificnim za

svaki tip kontrolnog paketa, te preostalu duljinu. Tablica 2.1 prikazuje izgled fiksnog

zaglavlja u MQTT kontrolnom paketu.

Tip MQTT kontrolnog paketa

Ovo polje velicine 4 bita oznacava o kakvom se tipu MQTT kontrolnog paketa radi.

Predstavljen je kao 4-bitna brojcana vrijednost bez predznaka (eng. unsigned value).

Popis svih mogucih tipova se nalazi u tablici 2.2

11

Bit 7 6 5 4 3 2 1 0

1. bajt Tip MQTT kontrolnog paketa Zastavice specificne za svaki tip

MQTT kontrolnog paketa

2. bajt Preostala duljina paketa

Tablica 2.1: Prikaz strukture fiksnog zaglavlja u MQTT kontrolnom paketu

Naziv Broj Smjer Opis

(Rezervirano) 0 (Nedozvoljeno) (Rezervirano polje)

CONNECT 1 Klijent -> Poslužitelj Klijent zahtjeva povezivanje na

poslužitelj

CONNACK 2 Poslužitelj -> Klijent Potvrda uspješnog povezivanja

PUBLISH 3 Klijent -> Poslužitelj Objava na posrednika

PUBACK 4 Dvosmjerno Potvrda objave

PUBREC 5 Dvosmjerno Potvrda primitka objave

PUBREL 6 Dvosmjerno Otpuštanje objave

PUBCOMP 7 Dvosmjerno Objava dovršena

SUBSCRIBE 8 Klijent -> Poslužitelj Zahtjev za pretplatu

SUBACK 9 Poslužitelj -> Klijent Potvrda pretplate

UNSUBSCRIBE 10 Klijent -> Poslužitelj Zahtjev za otkazom pretplate

UNSUBACK 11 Poslužitelj -> Klijent Potvrda zahtjeva za otkazom

PINGREQ 12 Klijent -> Poslužitelj Zahtjev za ping-om

PINGRESP 13 Poslužitelj -> Klijent Odgovor na ping

DISCONNECT 14 Klijent -> Poslužitelj Zahtjev za odspajanje

(Rezervirano) 15 (Nedozvoljeno) (Rezervirano polje)

Tablica 2.2: Prikaz svih mogucih tipova MQTT kontrolnog paketa

Polje s kontrolnim zastavicama

Preostali bitovi u fiksnom zaglavlju predstavljaju polje s kontrolnim zastavicama,

koje su specificne za svaki tip MQTT kontrolnog paketa, što je prikazano u tablici 2.3.

12

Tip paketa Zastavice Bit 3 Bit 2 Bit 1 Bit 0

PUBLISH Korišteno u MQTT 3.1.1 DUP QoS QoS RETAIN

PUBREL (Rezervirano) 0 0 1 0

SUBSCRIBE (Rezervirano) 0 0 1 0

UNSUBSCRIBE (Rezervirano) 0 0 1 0

Tablica 2.3: Prikaz zastavica ovisno o tipu MQTT kontrolnog paketa

Samo se kod objave koriste zastavice koje postavljaju neke opcije, kod svih ostalih

tipova kontrolnih paketa su vrijednosti rezervirane za buduce nadogradnje te moraju

biti postavljene u one vrijednosti koje su navedene u tablici. Kako bi se smanjila

velicina tablice, navedeni su samo oni zahtjevi koji imaju neke specificne vrijednosti.

Kod svih ostalih zahtjeva su vrijednosti zastavica rezervirane i moraju biti svi bitovi

postavljeni u nulu.

Zastavice koje se kod objave koriste su redom:

– DUP - dupliciranje objave, odnosno dvostruko slanje PUBLISH kontrolnog

paketa

– QoS - kvaliteta usluge objave (opisano u poglavlju 2.3.4)

– RETAIN - zahtjev za zadržavanjem poruke (opisano u poglavlju 2.3.5)

Preostala duljina paketa

Ovo polje sadrži vrijednost preostale duljine paketa, ukljucujuci varijabilno za-

glavlje i sadržaj poruke, a ne sadrži bajtove korištene za dekodiranje polja za preostalu

duljinu paketa. Preostala duljina je pohranjena na sljedeci nacin: u jednom bajtu se 7

najmanje znacajnih bitova koristi za zapis vrijednosti duljine do 0 - 127, dok se naj-

znacajniji bit naziva "bit nastavka" te oznacava da li nakon tog bajta slijedi još jedan

bajt za zapis preostale duljine paketa. Najviše može biti 4 bajta. Tablica 2.4 prikazuje

nacin kodiranja, gdje je u svakom celiji prikazana vrijednost koja se kodira, a u zagradi

bajtovi koji se šalju. Najveca vrijednost koja se može zapisati je 268 435 455.

2.4.2. Varijabilno zaglavlje

Pojedini tipovi MQTT kontrolnih paketa sadrže varijabilno zaglavlje koje, koje se

nalazi izmedu fiksnog zaglavlja i sadržaja poruke. Ti tipovi su PUBLISH (koji ima

13

Od Do

0 (0x00) 127 (0x7F)

128 (0x80, 0x01) 16 383 (0xFF, 0x7F)

16 384 (0x80, 0x80, 0x01) 2 097 151 (0xFF, 0xFF, 0x7F)

2 097 152 (0x80, 0x80, 0x80, 0x01) 268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

Tablica 2.4: Prikaz kodiranja vrijednosti preostale duljine paketa

kvalitetu usluge vecu od nule), PUBACK, PUBREC, PUBREL, PUBCOMP, SUB-

SCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK. Sadržaj varijabilnog zaglavlja

ovisi o samom tipu kontrolnog paketa.

2.4.3. Sadržaj poruke

Neki tipovi MQTT kontrolnih paketa imaju i sadržaj poruke (eng. payload), kao

krajnji dio paketa. Tipovi paketa CONNECT, SUBSCRIBE, SUBACK i UNSUBS-

CRIBE moraju imati sadržaj poruke, dok je kod PUBLISH tipa paketa on opcionalan

i predstavlja samu poruku koju aplikacija šalje. Kod svih ostalih tipova kontrolnih

paketa nem sadržaja poruke.

2.5. Sigurnost u protokolu MQTT

Brojne su opasnosti moguce kad je u pitanju sigurnost, ukljucujuci kompromiti-

rane uredaje, dostupnost podataka pohranjenih na klijentima ili poslužiteljima, neže-

ljene efekte ponašanja protokola, uskracivanje usluge (eng. DoS - Denial of Service),

presretanje poruka te njihove izmjene, preusmjeravanje ili otkrivanje, ubacivanje kri-

votvorenih paketa itd. Stoga je potrebno omoguciti autentifikaciju korisnika i uredaja,

autorizaciju kod pristupa poslužiteljskim resursima te osiguranje integriteta i privat-

nosti MQTT kontrolnih paketa. Kao transportni protokol, MQTT se prvenstveno brine

o prijenosu poruka, a na izvršitelju je odgovornost da pruži mehanizme za sigurnost. U

vidu toga, MQTT brokeri mogu zahtijevani korisnicko ime i lozinku za autentifikaciju,

te se može koristiti SSL/TLS protokol za enkripciju.

14

Sigurnost na razini mreže

Kako bi se stvorila sigurna i pouzdana veza, moguce je koristiti fizicki osigurane

mreže ili virtualne privatne mreže (eng. VPN - Virtual Private Network kao temelje za

komunikaciju izmedu klijenta i posrednika. Ovaj mehanizam je posebice koristan kod

korištenja mostova (eng. gateway), gdje je most povezan s uredajima na jednoj strani,

te s posrednikom putem VPN-a s druge strane.

Sigurnost na razini prijenosa

Na ovoj razini je moguce koristiti TLS/SSL protokol za enkripciju prijenosa. Rijec

je o mehanizmu koji pruža pouzdan i siguran nacin zaštite sadržaja, tako da ga nitko

ne može procitati ako nije autoriziran za to.

Sigurnost na razini aplikacije

Protokol MQTT pruža identifikaciju klijenta te njegovu autorizaciju putem koris-

nickom imena i lozinke, Na posredniku je da kontrolira što pojedini uredaj smije raditi,

te kako se nositi s autentifikacijom. Takoder je moguce na aplikacijskoj razini kriptirati

sadržaj koji se šalje (eng. payload).

2.6. Protokol MQTT za senzorske mreže (MQTT-S)

Iako je protokol MQTT osmišljen da bude lagan, ima dva nedostatka kad je u pita-

nju primjena na ogranicenim cvorovima. Slanje MQTT poruka odvija se putem proto-

kola TCP, pri cemu je veza izmedu klijenta i posrednika trajna. U nekim okruženjima,

gdje postoji velika mogucnost od gubitka paketa te gdje su resursi oskudni, to može

predstavljati problem. Drugi nedostatak mogu predstavljani imena tema, koja mogu

biti veoma dugacka te tako neprakticna za korištenje sa standardom 802.15.4. Rje-

šenje navedenih nedostataka predstavlja proširenje protokola za korištenje u senzor-

skim mrežama, koje se naziva MQTT-S, Na slici 2.2 je prikazana arhitektura protokola

MQTT-S. Uobicajeno MQTT-S klijent sadrži i objavljivaca i pretplatnika te sa MQTT

brokerom komunicira putem mosta (eng. gateway) ili prosljeditelja (eng. forwarder).

Uloga prosljeditelja je prijenos poruka izmedu mreža, bez modifikacija, dok je uloga

mosta ujedno i prevodenje poruka izmedu protokola MQTT i MQTT-S. Stoga proslje-

ditelj mora s MQTT posrednikom komunicirati putem mosta, kao što je prikazano na

slici 2.2.

15

Slika 2.2: Prikaz mreže zasnovane na protokolima MQTT i MQTT-S

Druga korisna mogucnost je korištenje višestrukih mostova i prosljeditelja, što

omogucava podjelu opterecenja i redundanciju. Ta je opcija posebice korisna kod be-

žicnih mreža s niskom propusnošcu te s velikom vjerojatnošcu gubitaka. Protokol

MQTT-S ujedno omogucuje i mrežnu neovisnost jer može raditi s bilo kojim protoko-

lom koji pruža uslugu datagrama te jednako dobro radi sa štedljivim protokolom UDP,

kao i sa sigurnim protokolom TCP, gdje se komunikacija temelji na sjednicama. Kao

takav, ovaj protokol omogucava i posredništvo izmedu više izoliranih bežicnih mreža,

te izmedu razlicitih tipova mreža, kao što su primjerice Xbee i TinyOS.

16

3. Protokol CoAP

3.1. Uvod

Protokol CoAP (eng. Constrained Application Protocol) je specijalizirani softver-

ski protokol koji ogranicenim mrežnim cvorovima omogucava interaktivnu komuni-

kaciju preko standardnih mreža (kao što je Internet). Ovim protokolom se cilja na

jednostavne elektronicke uredaje (kao što su primjerice razni senzori, prekidaci, ven-

tili i brojni drugi uredaji), koji imaju malu procesnu snagu, malu potrošnju energije te

najcešce su povezani na mreže s niskom propusnošcu i cestim ispadanjima i gubitcima,

a potrebno ih je nadzirati ili upravljati daljinski, putem mreže. Protokol je razvijen od

strane organizacije otvorenih standarda, koja se volonterski bavi razvojem i promica-

njem Internet standarda, pod nazivom IETF (eng. Internet Engineering Task Force),

odnosno od strane radne grupe koja se bavi ogranicenim RESTful okruženjima, pod

imenom CoRE (eng. Constrained RESTful Environments). Smatra se da ce u buduc-

nosti, kompletiranjem protokola CoAP, milijuni uredaja u raznim domenama aplikacije

koristiti navedeni protokol.

Slika 3.1: Prikaz mreže zasnovane na protokolu CoAP

17

3.2. Znacajke protokola CoAP

U nastavku su navedene cinjenice koje su trebale biti zadovoljene pri oblikovanju

protokola CoAP te one ujedno predstavljaju i same znacajke protokola CoAP

– Ograniceni web protokol koji zadovoljava M2M (eng. machine-to-machine)

zahtjeve

– Mogucnost povezivanja s DTLS (eng. Datagram Transport Layer Security)

slojem u vidu sigurnosti

– Asinkrona razmjena poruka

– Mala kolicina dodatnih podataka (eng. overhead) koje je potrebno dodati na

sam sadržaj poruke

– Mala kompleksnost parsiranja

– Podrška za URI (eng. Uniform Resource Identifier) i Content-Type

– Jednostavne mogucnosti za posredovanje (eng. proxy) i spremanje u predme-

moriju (eng. caching) bazirano na maksimalno dopuštenoj starosti poruke

– Podrška za komunikaciju putem protokola UDP (eng. User Datagram Proto-

col), uz opcionalnu podršku za unicast i multicast zahtjeve

– HTTP mapiranje bez pamcenja stanja (eng. stateless), koje omogucava izgrad-

nju proxy-a koji ce na uniforman nacin omogucavati pristup CoAP resursima

pomocu protokola HTTP, ili za ostvarenje jednostavnih HTTP sucelja putem

protokola CoAP

– Podrška za otkrivanje resursa koje pružaju poznati CoAP servisi

– Jednostavna pretplata na resurs, koja rezultira push notifikacijama

3.3. Usporedba protokola CoAP i HTTP

Protokol HTTP (eng. HyperText Transfer Protocol je aplikacijski protokol nami-

jenjen distribuiranim i kolaborativnim informacijskim sustavima zasnovanim na struk-

turi podataka pod imenom hypermedia. Rijec je o nelinearnom mediju informacija,

koji se može sastojati od obicnog teksta, slika, grafika, zvucnih zapisa i logickih po-

veznica (eng. hyperlink), koje povezuju cvorove sa sadržajem. Izvorno se radilo samo

o obicnim tekstualnim dokumentima povezanim logickim poveznicama (eng. hyper-

text), odakle i ime u nazivu protokola. Protokol HTTP se temelji na REST (eng. Re-

presentational State Transfer) nacelima, gdje su informacije dostupne u obliku resursa

18

koje se identificira i kojima se pristupa pomocu uniformnog identifikatora resursa (eng.

URI - Uniform Resource Identificator). Aplikacije komuniciraju tako da razmjenjuju

reprezentacije tih resursa putem nekog protokola za prijenos, kao što je HTTP. REST

nacela podrazumijevaju pružanje metoda za dohvat, postavljanje, izmjenu i brisanje

sadržaja, kao što su GET, PUT, POST i DELETE metode. Kao takav, protokol HTTP

predstavlja temelj podatkovne komunikacije u WWW-u (eng. World Wide Web).

Medutim, protokol HTTP je odviše složen za ogranicene uredaje zbog svoje ra-

cunske složenosti i visoke potrošnje energije, te se temelji na protokolu TCP (eng.

Transfer Control Protocol) koristeci P2P (eng. Point-to-Point) model komunikacije,

koji nije prikladan za push notifikacije, gdje server klijentu dostavlja notifikacije bez

zahtjeva klijenta. Štoviše, kolicina dodatnih podataka (eng. overhead) kod protokola

TCP je odviše velika zbog mnoštva opcija koje pruža, a koje su nepotrebne jednostav-

nim racunalnim cvorovima kod Interneta stvari. Stoga je ideja CoRE radne grupe bila

prilagoditi i pojednostaviti protokol HTTP za korištenje na takvim uredajima, tako da

se i dalje slijede REST nacela. S druge strane, protokol CoAP je temeljen na protokolu

UDP, koji je mnogo jednostavniji i zahtjeva manje dodatnih informacija na sam sadr-

žaj poruke, te omogucava slanje IP datagrama prema više zainteresiranih primatelja u

jednom prijenosu, pod imenom IP multicast, što je potrebno za grupnu komunikaciju

u IoT-u. Problem protokola UDP je njegova nepouzdanost, pa je u sklopu protokola

CoAP definiran mehanizam ponovnog slanja poruke (retransmisije), te mehanizam ot-

krivanja dostupnih resursa s njihovim opisom.

Slika 3.2: Prikaz usporedbe strukture protokola CoAP i HTTP

Slika 3.2 prikazuje usporedbu protokola CoAP i HTTP. S lijeve strane je prikazana

komunikacija razmjenom reprezentacija resursa putem HTTP protokola, koji koristi

protokol TCP. S desne strane je prikazana komunikacija pomocu protokola CoAP, gdje

19

se šalju poruke putem protokola UDP, u obliku zahtjeva i odgovora. Kao primjer pri-

jenosa je naveden 6LoWPAN (eng. IPv6 over Low-Power Wireless Area Networks)

standard koji omogucuje IPv6 standard i na veoma ogranicenim mrežama. IPv6 je

najnovija inacica IP (eng. Internet Protocol) komunikacijskog protokola za identifika-

ciju i lociranje racunala na mreži, te usmjeravanje prometa na Internetu, Na slici 3.3

je prikazana usporedba velicina i strukture poruka za slanje putem protokola HTTP,

putem protokola CoAP preko protokola IP te putem protokola CoAP preko navedenog

standarda 6LoWPAN.

Slika 3.3: Prikaz usporedbe strukture i velicine poruke protokola HTTP i CoAP

3.4. Strukturni model protokola CoAP

Strukturni model protokola CoAP je slican klijent-poslužitelj modelu kod proto-

kola HTTP. Sastoji se od dva sloja, koja su prikazana na slici 3.2; sloja poruka (eng.

Message Layer), koji se brine za komunikaciju putem protokola UDP, te sloja zahtjeva

i odgovora (eng. Request/Response Layer).

3.4.1. Sloj poruka

Sloj poruka podržava cetiri vrste poruka; potvrdujuci tip poruke (CON), nepotvr-

dujuci tip poruke (NON), potvrdnu poruku (eng. acknowledgement) (ACK) te poruke

za resetiranje (RST). Pri tome, svaka poruka koja se šalje ima svoj jedinstveni identifi-

kator (ID). Prijenos poruka može biti pouzdan i nepouzdan.

20

Pouzdani prijenos poruka

Kod pouzdanog prijenosa poruka, pošiljatelj šalje potvrdujuci tip poruke (CON), te

ceka na potvrdnu poruku (ACK) od strane primatelja. Ako u odredeno vrijeme ceka-

nja (eng. time-out) ne pristigne potvrdna poruka s istim identifikatorom kao i poslana

poruka, pošiljatelj radi retransmisiju te ponovno šalje istu poruku. Svakom retransmi-

sijom se vrijeme cekanja eksponencijalno smanjuje. Ako primatelj ne može uspješno

procesirati primljenu poruku, umjesto potvrdne poruke (ACK) šalje poruku za reseti-

ranje (RST). Primjer pouzdanog prijenosa je prikazan na slici 3.4. S lijeve strane se

nalazi uspješan prijenos poruke, gdje klijent šalje potvrdujucu poruku poslužitelju, na

što poslužitelj odgovara s potvrdnom porukom. S desne strane se nalazi prijenos kod

kojeg je došlo do greške u procesiranju poruke sa strane poslužitelja, te se šalje poruka

za resetiranje. Unutar uglatih zagrada nalazi se identifikator poruke.

Slika 3.4: Prikaz pouzdanog prijenosa poruka kod protokola CoAP

Nepouzdani prijenos poruka

Kod nepouzdanog prijenosa poruka pošiljatelj šalje nepotvrdujuci tip poruke (NON).

Primatelj ne mora slati potvrdnu poruku, odnosno nece doci do retransmisije u tom slu-

caju. Medutim, poruka NON i dalje mora sadržavati identifikator jer se u slucaju po-

greške kod procesiranja poruke sa strane primatelja šalje poruka za resetiranje. Primjer

takvog prijenosa je prikazan na slici 3.5

3.4.2. Sloj zahtjeva i odgovora

Postoje cetiri vrste sloja zahtjeva i odgovora: u istom prijenosu poruka (eng. piggy-

backed), u odvojenom prijenosu poruka te u odvojenom prijenosu poruka bez potvrde.

21

Slika 3.5: Prikaz nepouzdanog prijenosa poruka kod protokola CoAP

U istom prijenosu poruka

Prikaz zahtjeva i odgovora u istom prijenosu poruka nalazi se na slici 3.6. Klijent

šalje potvrdujuci (CON) ili nepotvrdujuci (NON) tip poruke, u ovom konkretnom slu-

caju pita za datum i vrijeme, te odmah prima odgovor u sklopu potvrdne poruke (ACK).

S desne strane se nalazi prikaz odgovora, kad klijent zahtijeva nepostojeci resurs.

Slika 3.6: Prikaz zahtjeva i odgovora u istom prijenosu poruka

U odvojenom prijenosu poruka

Prikaz zahtjeva i odgovora u odvojenom prijenosu poruka nalazi se na slici 3.7.

Klijent šalje zahtjev pomocu potvrdujuceg (CON) tipa poruke, u ovom konkretnom

slucaju pita za datum i vrijeme. Medutim, server ne može odmah odgovoriti na zahtjev

pa šalje praznu potvrdnu poruku (ACK), a naknadno šalje odgovor pomocu potvrduju-

ceg (CON) tipa poruke, na što klijent odgovara praznom potvrdnom porukom (ACK).

U odvojenom prijenosu poruka bez potvrde

Prikaz zahtjeva i odgovora u odvojenom prijenosu poruka nalazi se na slici 3.8.

U ovom slucaju klijent poslužitelju šalje zahtjev pomocu nepotvrdujuceg (NON) tipa

22

Slika 3.7: Prikaz zahtjeva i odgovora u odvojenom prijenosu poruka

poruke, a istim tipom poruke poslužitelj šalje odgovor. Ni klijent ni poslužitelj ne

potvrduju jedno drugome primitak poruke.

Slika 3.8: Prikaz zahtjeva i odgovora u odvojenom prijenosu poruka bez potvrde

3.5. Format poruke u protokolu CoAP

Protokol CoAP se temelji na razmjeni jednostavnih poruka putem protokola UDP,

pri cemu jedna poruka predstavlja jedan UDP datagram. Dodatno, razmjena se može

vršiti i putem protokola DTLS, što je opisano u poglavlju , te putem nekog drugog

protokola kao što su SMS, TCP ili SCTP, što nije pokriveno u ovom radu. Poruke su

u jednostavnom binarnom obliku, te je njihov format prikazan na slici 3.9. Poruka

pocinje sa zaglavljem fiksne velicine 4 bajta, kojeg slijedi token promjenjive velicine

od 0 do 8 bajta. Zatim slijedi niz od nula ili više opcija protokola CoAP, u TLV

23

(eng. Type-Length-Value) obliku, ukljucujuci tip opcije, duljinu vrijednosti te samu

vrijednost opcije. Na kraju se opcionalno nalazi sam sadržaj poruke (eng. payload).

Slika 3.9: Prikaz formata poruke u protokolu CoAP

3.5.1. Zaglavlje poruke

Zaglavlje poruke se sastoji od 5 polja, koja ukljucuju verziju protokola, tip poruke,

duljinu tokena, kodnu oznaku poruke, te identifikator poruke.

Verzija protokola (VER)

Ovo polje oznacava verziju protokola CoAP koja se koristi za slanje. Sastoji se

od brojevne vrijednosti bez predznaka (eng. unsigned integer) predstavljene s 2 bita.

Trenutna verzija protokola je 1, tako da sve implementacije ovog protokola moraju to

polje u zaglavlju postaviti na vrijednost "01". Ostale vrijednosti su rezervirane za bu-

duce verzije protokola, te poruke koje ne sadrže vrijednost "01" trebaju biti ignorirane.

Tip poruke (T)

Ovo polje sadrži broj, koji je takoder predstavljen kao 2-bitna brojevna vrijednost

bez predznaka, te oznacava tip poruke; potvrdujuci tip poruke (0), nepotvrdujuci tip

poruke (1), potvrdna poruka (2) te poruka za resetiranje (3).

Duljina tokena (TKL)

Ovo polje oznacava duljinu tokena, koji slijedi nakon zaglavlja, kako bi parser

znao da li token postoji i koliko procitanih bajtova nakon zaglavlja predstavlja token

(od 0 do 8 bajtova). Ovaj podatak je predstavljen kao 4-bitna brojevna vrijednost bez

predznaka, koja može sadržavati vrijednost od 0 do 15. Medutim, vrijednosti od 9-15

su rezervirane i ne smiju biti korištene.

24

Kodna oznaka poruke (Code)

Ovo polje sadrži 8-bitnu brojevnu vrijednost bez predznaka, koja je podijeljena na

dva dijela. Prva 3 najznacajnija bita predstavljaju klasu, koja može poprimiti vrijed-

nosti od 0 do 7, te oznacava radi li se o zahtjevu (0), odgovoru o uspjehu (2), odgovoru

o pogrešci klijenta (4) ili odgovoru o pogrešci poslužitelja (5). Ostale vrijednosti su re-

zervirane i ne smiju se koristiti. Preostalih 5 bitova predstavlja detalje o poruci, koje u

slucaju zahtjeva oznacavaju tip zahtjeva; GET (0), POST (1), PUT (2) ili DELETE (3),

a u slucaju odgovora predstavljaju kod odgovora. Radi lakšeg razumijevanja, kodna

oznaka poruke se predstavlja u obliku a.bb, gdje "a" predstavlja klasu (0-7), a "bb"

detalje (0-31). Sve moguce kodne oznake su prikazane u tablici 3.1, a nenavedene

kombinacije su rezervirane i ne smiju se koristiti.

Identifikator poruke (Message ID)

Ovo polje sadrži 16-bitnu brojevnu vrijednost bez predznaka, koja predstavlja je-

dinstveni identifikator poruke. Koristi se za detektiranje duplikata u porukama, te za

povezivanje potvrdnih poruka i poruka za resetiranje s odgovarajucim potvrdujucim ili

nepotvrdujucim porukama koje su ih izazvale.

3.5.2. Token u poruci

Nakon zaglavlja u poruci dolazi token, koji je opcionalan i može biti duljine od

0 do 8 bajtova, što je definirano poljem TKL u zaglavlju poruke. Token se koristi

za povezivanje zahtjeva i odgovora. Primjerice, ako klijent od poslužitelja zahtjeva

neki resurs, a koristi se metoda gdje se odgovor šalje u odvojenom prijenosu poruka,

identifikator poruke ce biti razlicit za zahtjev i odgovor te kao takav nije prikladan za

povezivanje. Zato se koristi token koji u zahtjevu i odgovoru mora imati istu vrijednost.

3.5.3. Opcije u poruci

Nakon opcionalnog tokena, u poruci slijede opcije, kojih može biti nula ili više.

Protokol CoAP definira brojne opcije koje mogu biti ukljucene u poruku, a prikazane

su u tablici 3.2. Pri tome je svaka opcija predstavljena samim brojem opcije, duljinom

vrijednosti opcije te samom vrijednošcu opcije.

Slika 3.10 prikazuje format pojedine opcije u poruci. Svaka opcija se sastoji od

udaljenosti (delta), duljine vrijednosti opcije, proširene udaljenosti opcije (ako je po-

25

Kod Klasa poruke Detalji poruke

0.00 Prazna poruka -

1.00 Zahtjev GET

1.01 Zahtjev POST

1.02 Zahtjev PUT

1.03 Zahtjev DELETE

2.01 Uspjeh Created (resurs kreiran)

2.02 Uspjeh Deleted (resurs obrisan)

2.03 Uspjeh Valid (važeci resurs)

2.04 Uspjeh Changed (izmijenjeni resurs)

2.05 Uspjeh Content (sadržaj resursa)

4.00 Pogreška klijenta Bad Request (neispravan zahtjev)

4.01 Pogreška klijenta Unauthorized (neautorizirani zahtjev)

4.02 Pogreška klijenta Bad Option (neispravna opcija)

4.03 Pogreška klijenta Forbidden (nedozvoljeni pristup)

4.04 Pogreška klijenta Not Found (resurs nije pronaden)

4.05 Pogreška klijenta Method Not Allowed (nedozvoljena metoda)

4.06 Pogreška klijenta Not Acceptable (nedozvoljeni zahtjev)

4.12 Pogreška klijenta Precondition Failed (neispunjeni preduvjeti)

4.13 Pogreška klijenta Request Entity Too Large (preveliki traženi entitet)

4.15 Pogreška klijenta Unsupported Content-Format (Nepodržani format sadržaja)

5.00 Pogreška poslužitelja Internal Server Error (unutarnja greška poslužitelja)

5.01 Pogreška poslužitelja Not Implemented (tražena metoda nije implementirana)

5.02 Pogreška poslužitelja Bad Gateway (pogreška posrednika)

5.03 Pogreška poslužitelja Service Unavailable (usluga nedostupna)

5.04 Pogreška poslužitelja Gateway Timeout (isteklo vrijeme cekanja)

5.05 Pogreška poslužitelja Proxying Not Supported (posredništvo nije podržano)

Tablica 3.1: Prikaz mogucih kodnih oznaka poruke

26

Broj opcije Naziv opcije

0 (Rezervirano)

1 If-Match

3 Uri-Host

4 ETag

5 If-None-Match

7 (Uri-Port)

8 Location-Path

11 Uri-Path

12 Content-Format

14 Max-Age

Broj opcije Naziv opcije

15 Uri-Query

17 Accept

20 Location-Query

35 Proxy-Uri

39 Proxy-Scheme

60 Size1

128 (Rezervirano)

132 (Rezervirano)

136 (Rezervirano)

140 (Rezervirano)

Tablica 3.2: Prikaz mogucih opcija u poruci

trebno), proširene duljine vrijednosti opcije (ako je potrebno), te same vrijednosti op-

cije.

Udaljenost opcije (Option Delta)

Svaka opcija je predstavljena svojim brojem, koji govori o kojoj se opciji radi. Pri

tome se u poruku ne ukljucuje sam broj opcije vec se koristi princip udaljenosti (eng.

delta encoding). Stoga je nužno da opcije budu sortirane uzlazno po broju opcije, a

zatim se broj pojedine opcije dobiva kao zbroj prethodne poruke te udaljenosti trenutne

poruke (delta). Ovo polje sadrži 4-bitnu brojevnu vrijednost bez predznaka koja može

poprimiti vrijednosti od 0 do 12, te oznacava koliko je ta opcija udaljena od prethodne.

Preostale vrijednosti su rezervirane za posebne konstrukcije:

– vrijednost 13 oznacava da se koristi proširena vrijednost udaljenosti, koja slijedi

pocetni bajt, te je duljine 8 bitova (1 bajt) i sadrži udaljenost umanjenu za 13

– vrijednost 14 oznacava da se koristi proširena vrijednost udaljenosti, koja slijedi

pocetni bajt, te je duljine 16 bitova (2 bajta) i sadrži udaljenost umanjenu za 269

– vrijednost 15 je rezervirana oznaku pocetka sadržaja (eng. Payload Marker), te

ako je ova vrijednost postavljena, a cijeli bajt nije oznaka pocetka sadržaja, u

pitanju je neispravna poruka

27

Slika 3.10: Prikaz formata pojedine opcije u poruci

Duljina vrijednosti opcije (Option Length)

Vrijednost opcije, koja se nalazi na samom kraju, može biti promjenjive duljine pa

parser mora znati njenu duljinu, da bi znao koliko bajtova mora procitati. U ovom polju

se nalazi duljina vrijednosti opcije kao 4-bitna brojcana vrijednost bez predznaka. Od

toga, duljina može poprimiti vrijednosti od 0 do 12 u bajtovima, a preostale vrijednosti

su rezervirane za posebne konstrukcije:

– vrijednost 13 oznacava da se koristi proširena vrijednost duljine vrijednosti op-

cije, koja prethodi samoj vrijednosti opcije, te je duljine 8 bitova (1 bajt) i sadrži

udaljenost umanjenu za 13

– vrijednost 14 oznacava da se koristi proširena vrijednost duljine vrijednosti op-

cije, koja prethodi samoj vrijednosti opcije, te je duljine 16 bitova (2 bajta) i

sadrži udaljenost umanjenu za 269

– vrijednost 15 je rezervirana za buduca proširenja i ako je ovo polje postavljeno

u tu vrijednost, u pitanju je neispravna poruka

Vrijednost opcije

Ovo polje sadrži niz bitova duljine zadane u prethodno opisanom polju Option

Length. Duljina i format vrijednosti ovise o tome koja je opcija odabrana, a moguci

formati su prazna vrijednost kao niz bajtova duljine nula, neodredeni (nerazumljivi) niz

bajtova, brojcana vrijednost bez predznaka (eng. unsigned integer - uint), te znakovni

28

niz (eng. string).

3.5.4. Sadržaj poruke (Payload)

I zahtjevi i odgovori mogu ukljucivati sadržaj poruke (eng. payload) koji se na-

lazi na samom kraju poruke. Sadržaj poruke je opcionalan, te promjenjive duljine, a

njegova duljina se dobiva izracunom na temelju poznatih duljina svih ostalih dijelova

poruke te na temelju poznate duljine datagrama. Ako sadržaj postoji, prethodi mu oz-

naka koja ga odvaja od prethodnih dijelova poruke (eng. Payload Marker), a rijec je

o nizu od 8 jedinica odnosno o oznaci "0xFF" u heksadecimalnom obliku. Medutim,

takav niz bitova bi se mogao pojaviti i unutar same vrijednosti opcije ili njene duljine,

pa se niz "0xFF" kao oznaka pocetka sadržaja poruke uzima samo na pocetku pojedine

opcije. Ako tip poruke ne definira postojanje sadržaja poruke, pošiljatelj ga ne smije

ukljuciti, odnosno primatelj ga mora ignorirati.

Sam format sadržaja poruke ovisi o tipu poruke i tipu sadržaja koji se šalje. Kod

zahtjeva i odgovora koji oznacavaju uspjeh, sadržaj tipicno podrazumijeva reprezenta-

ciju resursa ili rezultat zatražene akcije. Format je specificiran unutar opcije "Content-

Format Option", a ako ta opcija nije specificirana u poruci, ne postoji podrazumijevani

(eng. default) format nego aplikacija mora sama zakljuciti o kojem formatu se radi.

Ako je rijec o poruci koja oznacava grešku klijenta ili poslužitelja, a "Content-Format

Option" opcija nije postavljena, sadržaj poruke predstavlja dijagnostiku u obliku co-

vjeku citljive poruke koja pobliže opisuje nastalu grešku, te taj sadržaj mora biti kodi-

ran koristeci UTF-8 standard. Dodatno, klijent može pomocu opcije "Accept Option"

poslužitelju dati do znanja koji format preferira. U suprotnom ce poslužitelj poslati

sadržaj poruke u onom formatu kojeg on preferira. Podržani su razni oblici sadržaja,

kao što su JSON, XML, CBOR, EXI i mnogi drugi.

3.6. Sigurnost u protokolu CoAP

Osim same funkcionalnosti protokola, potrebno je obratiti pozornost i na sigurnost,

kako bi se zaštitila komunikacija medu uredajima. Tri glavna elementa sigurnosti, koje

treba uzeti u obzir, su integritet imenovanja, autentifikacija i povjerljivost. Sam proto-

kol CoAP ne pruža mehanizme za autentifikaciju i autorizaciju. Rješenje, koje može

zadovoljiti sva tri elementa, je korištenje sigurnosnog protokola DTLS (eng. Data-

gram Transport Layer Security) (prikazano na slici 3.11), koji aplikacijama baziranim

na datagramima omogucuje sigurniju komunikaciju tako da se sprjecava prisluškivanje

29

te izmjenjivanje i falsificiranje poruke. Baziran je na TLS protokolu, kojeg koristi pro-

tokol HTTP za komunikaciju putem protokola TCP, te pruža slicne sigurnosne moguc-

nosti. Dok je kod protokola DTLS sadržana semantika donjeg sloja (eng. underlying

layer), tako da kod protokola za strujanje (eng. streaming) ne dolazi do kašnjenja, na

aplikacijskoj razini je potrebno pobrinuti se za probleme kao što su gubitak datagrama,

te fragmentacija podataka zbog velicine paketa koja prelazi velicinu datagrama. Me-

dutim, kod protokola CoAP je protokol DTLS modificiran tako da su dodane tri nove

mogucnosti koje rješavaju te probleme:

1. Retransmisija u slucaju gubitka paketa

2. Dodjeljivanje brojeva datagramima kod fragmentacije, kako bi se sacuvao redos-

lijed

3. Detekcija ponavljanja datagrama

Slika 3.11: Prikaz korištenja protokola CoAP preko sigurnosnog protokola DTLS

Tijekom faze rezerviranja (eng. provisioning phase), svakom uredaju baziranom na

protokolu CoAP je potrebno osigurati sve sigurnosne informacije koje su mu potrebne,

ukljucujuci kljuceve te pristupne kontrolne liste. Nakon te faze, uredaj ce se nalaziti u

jednom od cetiri sigurnosna stanja:

– NoSec stanje u kojem je DTLS iskljucen te nema nikakve sigurnosti na razini

protokola. Paketi se šalju putem obicnog protokola UDP te preko IP protokola,

30

i koristi se klasicna CoAP shema i port. Jedina sigurnost je da se sprijeci poten-

cijalne napadace da šalju ili primaju pakete unutar mreže sa CoAP cvorovima.

– PreSharedKey stanje u kojem je DTLS ukljucen te postoji lista unaprijed po-

dijeljenih zajednickih kljuceva, gdje svaki kljuc sadrži listu cvorova s kojima

se taj kljuc može koristiti za komunikaciju. U ekstremnim slucajevima, mo-

guce je da svaki cvor ima svoj kljuc (1:1 odnos cvor/kljuc). Ako dva ili više

cvora dijele isti kljuc, on im omogucuje da se autentificiraju samo kao clanovi

te grupe, ne i kao pojedinacni entitet.

– RawPublicKey stanje u kojem je DTLS ukljucen te uredaj posjeduje asime-

tricni par kljuceva bez certifikata (eng. raw public key). Osim toga, uredaj

posjeduje i svoj identitet dobiven iz javnog kljuca, te listu identiteta cvorova s

kojima smije komunicirati.

– Certificate stanje u kojem je DTLS ukljucen te uredaj, poput prethodnog sta-

nja, ima asimetrican par kljuceva no ovog puta sa X.509 certifikatom koji ga

povezuje s njegovim autoritetom, koji mu je pridijeljen od strane cvora koji

uživa zajednicko povjerenje (eng. common trust root). Uredaj takoder posje-

duje listu povjerljivih cvorova, koje može koristiti za validaciju svog certifikata.

Od navedenih stanja, NoSec i RawPublicKey stanja su obavezna za implementaciju,

dok ostala dva nisu. Štoviše, na pojedinim ogranicenim cvorovima (u vidu ogranicene

memorije) te ogranicenim mrežama (u vidu ogranicene protocnosti te visokih zahtjeva

za skalabilnost) nije moguce primijeniti sva navedena stanja. Pojedine implementacije

mogu dodati veliku složenost poruke, te samim time veliku kolicinu dodatnih poda-

taka potrebnih za slanje pocetne poruke za rukovanje (eng. handshake). Jednom kad

je sigurna veza uspostavljenja, protokol DTLS dodaje ogranicenu kolicinu dodatnih

podataka, koja prosjecno iznosi oko 13 bajtova.

Kod korištenja protokola DTLS, svaki cvor koji se ponaša kao CoAP klijent se isto

tako mora moci ponašati i kao DTLS klijent. Prvo je potrebno uspostaviti sjednicu

(eng. session) sa serverom na odgovarajucem portu. Zatim se vrši rukovanje (eng.

handshake), nakon kojeg klijent može poslati prvi CoAP zahtjev. Sve CoAP poruke se

pakiraju kao DTLS podatci (eng. DTLS Application Data) te šalju kao DTLS paketi.

U vidu toga, bilo je potrebno definirati neka nova pravila. U sloju poruka, kako bi se

uspješno povezale potvrdne poruke i poruke za resetiranje s pripadajucim zahtjevima,

moraju biti poslane unutar iste DTLS sjednice i unutar iste vremenske epohe, uz isti

identifikator poruke. Kod retransmisije potvrdne poruke, koristi se novi broj DTLS

sekvence za svaki pokušaj, no identifikator poruke ostaje isti pa primatelj treba izvršiti

31

provjeru za duplikate. Analogno tome, u sloju zahtjeva i odgovora, odgovor mora biti

poslan koristeci istu DTLS sjednicu, istu vremensku epohu i isti identifikator poruke

kao i zahtjev. Ako se pošalje odgovor tipa NoSec na DTLS zahtjev, odgovor mora biti

odbijen.

3.7. Princip rada

U usporedbi s web protokolima, CoAP je decentralizirani protokol, koji omogu-

cava senzorima i cvorovima da se povezuju jedan s drugim te objavljuju poruke jedan

drugome. Zadani UDP portovi za protokol CoAP su "5683" kod verzije bez korištenja

protokola DTLS (coap:// ) odnosno "5684" kod verzije s korištenjem protokola DTLS

(coaps:// ). Komunikacija funkcionira tako da klijent pošalje zahtjev na poslužitelj,

na temelju adrese te imena resursa kojeg želi dohvatiti. Primjerice, ako klijent s pos-

lužitelja s adresom "192.168.256.3" želim dohvatiti podatak o temperaturi, poslati ce

GET zahtjev na URI "coap://192.168.221.3:5683/temperature". CoAP podržava i sla-

nje velikih sadržaja pomocu fragmentacije, odnosno kroz više zahtjeva, što se naziva

Blockwise prijenos. Postoji i podrška za multicast transmisiju jednog zahtjeva prema

više cvorova, što omogucava efikasno otkrivanje resursa te nadogradnje.

3.7.1. Pretplata na promjenu stanja

Protokol CoAP omogucava klijentu da se pretplati kao promatrac (eng. observer)

na subjekt, tako da dobiva obavijesti svaki puta kada se stanje subjekta promijeni. Ovaj

je mehanizam baziran na istoimenom oblikovnom obrascu. Iako se na ovaj nacin sma-

njuje potreba za konstantnim slanjem zahtjeva sa strane klijenta, u svrhu provjere sta-

nja, uvodi se nova dodatna kolicina podataka potrebna za slanje poruke. Klijent postaje

promatrac tako da u zaglavlju poruke postavi Observer opciju. Nakon pretplacivanja,

klijent ce primati obavijesti sve dok eksplicitno ne pošalje poruku za otkazivanje pret-

plate, dok ne dode do situacije kad nije poslana potvrdna poruka (ACK) na potvrdujuci

tip poruke (CON), ili sve dok ne istekne vrijeme maksimalne starosti posljednje prim-

ljene obavijesti. Primjer upotrebe ovog mehanizma je pretplata svijetla na senzor, što

je prikazano na slici .

32

Slika 3.12: Primjer upotrebe mehanizma promatraca pomocu svijetla i senzora

3.7.2. Otkrivanje dostupnih resursa

Ako klijent ne zna za resurse koje CoAP ili HTTP poslužitelj može pružiti, može

se poslužiti metodom otkrivanja dostupnih resursa, slanjem GET zahtjeva na resurs pod

imenom "/.well-known/core" odnosno puni URI bi izgledao ovako: "coap://192.168.221.3/.well-

known/core". Kao odgovor dobiva listu svih poznatih resursa u sklopu tog direktorija.

Protokol CoAP takoder podržava i filtriranje rezultata korištenjem upita kao parametra

u URI-u, kao što su primjerice "/.well-known/core?rt=light-lux" ili nešto složeniji upit

"/.well-known/core?search*".

33

4. Uredaji Arduino

4.1. O Arduino platformi

Arduino je platforma otvorenog koda (eng. open-source) namijenjena za modeli-

ranje i izgradnju elektronickih uredaja. Platforma obuhvaca hardver, u obliku samih

razvojnih ploca s mikrokontrolerima (prikazane na slici 4.1) te pripadajucih dodataka,

koji se nazivaju štitovi (eng. shields), te softver, ukljucujuci programsko razvojno

okruženje, pod nazivom Arduino IDE, te sve pripadajuce programske knjižnice za pi-

sanje programskog koda.

Preteca Arduino uredaja je bila razvojna platforma Wiring, koju je 2004. godine

razvio kolumbijski student Hernando Barragán u sklopu svog diplomskog rada. Ideja

je bila da se naprave jeftini i jednostavni za korištenje alati za razvoj digitalnih proje-

kata, razumljivi i onima bez inženjerskih vještina. Platforma se sastojala od razvojne

ploce sa Atmega128 mikrokontrolerom, razvojnog okruženja i pripadajucih program-

skih knjižnica za programiranje mikrokontrolera.

Tada nadzornik Hernandovog projekta, Massimo Banzi, je s Davidom Mellis-om i

Davidom Cuartielles-om dodao podršku za jeftiniji mikrokontroler ATmega8. Umjesto

da rade na Hernandovom projektu, oni su kopirali njegov kod i nastavili raditi na svom

novom projektu pod nazivom Arduino. Projekt je ime dobio po nazivu kafica u tali-

janskom gradu Ivrei, u kojem su se cesto nalazili. Prvi Arduino je proizveden 2005.

godine, od strane talijanske tvrtke SmartProjects. Danas naziv Arduino ne obuhvaca

samo pripadni hardver i softver vec citav projekt, ukljucujuci i veliku zajednicu ko-

risnika, te brojne hardverske dodatke i programske knjižnice dostupne za navedene

uredaje.

34

4.2. Razvojne ploce

4.2.1. Uvod

Hardverski dio Arduino platforme predstavlja razvojna ploca. Nekoliko Arduino

razvojnih ploca je prikazano na slici 4.1, ukljucujuci ploce Uno, YUN i Due. Srce

razvojne ploce je mikrokontroler, a osim njega, na ploci se nalaze razni drugi sklopovi,

kao što je sklop za napajanje, sklop za programiranje mikrokontrolera, sklop za prikaz

serijske veze na racunalu putem USB veze te razni prikljucci i pinovi.

Slika 4.1: Arduino Uno, YUN i Due razvojne ploce

Mikrokontroler

Mikrokontroler (eng. MCU - Microcontroller Unit je središnja komponenta svake

Arduino razvojne ploce. Rijec je o malenom racunalu u obliku integriranog kruga

(eng. SoC - System on Chip), koje se sastoji od procesorske jezgre, programske i radne

memorije te programabilnog ulazno-izlaznog sucelja. Takav dizajn, gdje su navedene

komponente integrirane u jednu komponentu, smanjuje velicinu ali i cijenu sklopovlja,

za razliku od dizajna koji koristi odvojene komponente. Rijec je o racunalima znatno

slabijim od klasicnih osobnih racunala, gdje se takt procesora krece od nekoliko MHz

pa do nekoliko desetaka MHz, a kolicina radne i programske memorije od nekoliko kB

pa do nekoliko desetaka kB. Medutim, i namjena takvih racunala se znatno razlikuje

od one osobnih racunala, pa nisu ni potrebne vece performanse. Štoviše, za pojedine

namjene, u svrhu smanjenja potrošnje energije, mikroprocesori mogu raditi i na takto-

vima od nekoliko kHz. Mikrokontroleri se pretežno koriste u ugradbenim racunalnim

sustavima, primjerice u automobilima (sustav za upravljanje motorom, klima uredaj,

sustav zracnih jastuka itd.), u namjenskim uredajima kao što su printeri, skeneri, audio

uredaji, u bijeloj tehnici, u alarmnim sustavima, sustavima za upravljanje grijanjem

itd.

35

Slika 4.2: ATmega16 mikrokontroler

Programabilno ulazno-izlazno sucelje

Ono što mikrokontrolere cini specificnim i što predstavlja bitni aspekt njihove pri-

mjene je integrirano programabilno ulazno-izlazno sucelje. Arduino razvojne ploce

koriste mikrokontrolere s miješanim signalima, odnosno posjeduju i analogne i digi-

talne ulaze i izlaze. Kod digitalnih ulaza, program provjerava da li na odredenom pinu

postoji napon. Ako postoji, to se interpretira kao logicka jedinica, a u suprotnom, kao

logicka nula. Primjer korištenja takvih pinova su tipkala, gdje se pritiskom na tipku

dovede napon na pin, koji je prethodno bio pritegnut na masu, ili se pritiskom spoji

na masu, ako je prethodno bio pritegnut na napajanje. Ta se promjena u programu

detektira te se poduzimaju odgovarajuce akcije. Analogno tome, svaki digitalni pin

može se koristiti i kao izlaz; ako se izlaz postavi u logicku jedinicu, na tom pinu ce

se pojaviti napon napajanja, u suprotnom ce napon biti 0 V. Tako se mogu primjerice

ukljucivati i iskljucivati razni elementi i uredaji, kao što su svjetlece diode ali i mnogo

veci potrošaci pomocu releja ili tranzistora.

Kod analognih signala, Arduino uredaji sadrže pretvarac analognih signala u digi-

talni (ADC - Analog to Digital Converter, pomocu kojeg mjere napon na odredenom

pinu. Vrijednost napona se pomocu pretvaraca pretvara u digitalnu vrijednost. Raspon

dobivenih digitalnih vrijednosti ovisi o broju bitova pretvaraca, pa je tako raspon za

10-bitni pretvarac od 0 do 210-1 odnosno od 0 - 1023. Primjer korištenja analognih

ulaza je za povezivanje raznih senzora, primjerice temperaturnog senzora, pri cemu se

izmjereni napon pomocu prikladnih formula pretvara u podatak o temperaturi. Moguce

36

je i generiranje analognih izlaza ovisno o postavljenoj vrijednosti u programu, koris-

teci PWM (eng. Pulse Width Module), kako bi se, primjerice, programski podesio

intenzitet svjetlosti svjetlece diode, ili brzina vrtnje motora.

Arduino uredaji mogu sadržavati i druga sucelja, kao što su serijska veza (UART),

I2C protokol te brojni drugi.

Slika 4.3: Prikaz povezivanja raznih elemenata na Arduino razvojnu plocu

4.2.2. Arduino Uno R3

U sklopu ovog diplomskog rada, za usporedbu protokola MQTT i CoAP, korišten

je uredaj Arduino Uno, poznat i po imenu Genuino Uno za tržišta izvan Sjedinjenih

Americkih Država. Uno je najkorištenija i najpoznatija ploca iz Arduino obitelji, s

najboljom dokumentacijom, i predstavlja idealan izbor za pocetnike ali i za napredne

korisnike, ako su njegove specifikacije dovoljne za razvoj željenog projekta. Ime ploce

dolazi od talijanske rijeci uno, u prijevodu broj jedan, jer je oznacavalo izdavanje ver-

zije 1.0 Arduino IDE softvera.

Glavna komponenta Uno razvojne ploce je mikrokontroler ATmega328P s proce-

sorom takta 16 MHz, 32 KB programske flash memorije te 2 KB SRAM memorije.

Mikrokontroler je moguce jednostavno skinuti s ploce i na njegovo mjesto umetnuti

37

drugi, pa se u slucaju štete prouzrokovane nestrucnim rukovanjem razvojnom plocom

može jednostavno i jeftino zamijeniti samo mikrokontroler. Isto tako, moguce je na-

baviti sam mikrokontroler koji je i nekoliko puta jeftiniji od cijele Arduino Uno ploce,

isprogramirati ga na ploci, te ga zatim koristiti zasebno u projektima.

Arduino Uno posjeduje 14 digitalnih ulazno-izlaznih pinova, od cega 6 pinova

može biti korišteno kao PWM izlaz, 6 analognih ulaza, I2C sucelje, UART sucelje

za serijsku vezu, integrirani kristal na 16 MHz te USB prikljucak za povezivanje s ra-

cunalom, DC prikljucak za napajanje, ICSP prikljucak (eng. header) za programiranje

mikrokontrolera s vanjskim programatorom, te gumb za resetiranje. Kao takav, uredaj

je jednostavan za korištenje. Uredaj se može napajati putem USB porta, ili putem DC

prikljucka naponom od 6 pa sve do 20 V, iako je preporuceni napon napajanja od 7 do

12 V, za siguran rad.

4.3. Arduino štitovi

Arduino štitovi (eng. shields) su proširenja za Arduino uredaje u obliku tiskanih

plocica, koje se povezuju na sam Arduino tako da se nataknu na plocu u postojece

pinove, bez ikakvih dodatnih povezivanja žica ili lemljenja. Moguce je štitove slagati

jedan na drugog, što je prikazano na slici 4.4, sve dokle god dva štita ne koriste iste

pinove, što bi dovelo do nemogucnosti rada jednog ili oba štita.

Slika 4.4: Prikaz dva štita nataknuta na Arduino plocu

38

Štitovi pružaju razne dodatne mogucnosti kao što je povezivanje na mrežu (žicano

i bežicno), ili izravno na internet (3G moduli), pozicioniranje u prostoru (eng. GPS

- Global Positioning System), bežicna komunikacija (Xbee, Bluetooth), upravljanje

motorima, upravljanje LCD (eng. Liquid Crystal Display) zaslona, povezivanje raznih

senzora za mjerenje temperature, vlage te mnoge druge. Na slici 4.5 su pokazani samo

neki od brojnih štitova dostupnih za Arduino uredaje, ukljucujuci Wi-Fi, Ethernet,

TinkerKit (za povezivanje senzora i ostalih analognih i digitalnih komponenti), štit za

upravljanje motorima, štit s LCD zaslonom i tipkalima te GPS štit.

Slika 4.5: Prikaz nekoliko razlicitih štitova dostupnih za Arduino uredaje

4.3.1. Štit za bežicno povezivanje na mrežu (Wi-Fi)

Za implementaciju navedenih protokola u ovom radu je, kod povezivanja na mrežu,

korišten Wi-Fi štit prikazan na slici 4.6. Ovaj štit omogucava bežicno povezivanje

Arduino uredaja na mrežu koristeci 802.11 bežicni protokol (Wi-Fi). Baziran je na

HDG204 Wireless LAN 802.11b/g sustavu (eng. System in-Package), te AT32UC3

mikrokontroleru koji osiguravaju podršku za TCP i UDP veze. Takoder podržava i

WEP te WPA2 enkripcije, te se napaja s naponom od 5 V dobivenim iz samog ure-

daja Arduino. S Arduino uredajem komunicira putem SPI sucelja, te sadrži utor za

SD kartice, koji se može koristiti. Tu je i ICSP zaglavlje te FTDI konektor za otkri-

vanje grešaka putem serijske veze. Takoder, moguce je nadograditi sam štit pomocu

ugradenog mini USB konektora. Na štitu se nalaze 3 svjetlece diode koje oznaca-

39

vaju uspješnu vezu, grešku kod spajanja, trenutno slanje ili primanje podataka te jedna

opcionalna svjetleca dioda koja se može koristiti pri pisanju programa.

Slika 4.6: Arduino štit za bežicno povezivanje na mrežu (Wi-Fi)

Korištenje ovog štita je veoma jednostavno i intuitivno, te za isti postoji ugradena

programska knjižnica u samom Arduino IDE programskom okruženju. Primjer koda

za povezivanje na WPA2 mrežu je dan u izvornom kodu 4.1.

4.4. Programiranje Arduino uredaja

Za programiranje Arduino uredaja potrebno je USB kabelom plocu povezati s ra-

cunalom te koristiti neko integrirano razvojno okruženje za pisanje i prevodenje koda

te prebacivanje dobivenog binarnog strojnog koda na sam Arduino uredaj. Arduino

programi mogu biti pisani u bilo kojem programskom jeziku za koji postoji prevoditelj

(eng. compiler) koji taj kod prevodi u binarni strojni kod. Najpoznatije i najkorištenije

razvojno okruženje je Arduino IDE okruženje, dok sam Atmel kao proizvodac mi-

krokontrolera na Arduino plocama za svoje mikrokontrolere pruža razvojno okruženje

Atmel Studio, odnosno pod starijim nazivom AVR Studio. Štoviše, moguce je podesiti

40

#include <WiFi.h>

char ssid[] = "NekaMreza"; // Naziv mreze (SSID)

char pass[] = "12345678"; // Lozinka mreze

int status = WL_IDLE_STATUS; // Status Wi-Fi radija

void setup() {

Serial.begin(9600); // Inicijaliziranje serijske veze

Serial.println("Pokusaj povezivanja na bezicnu mrezu...");

status = WiFi.begin(ssid, pass); // Pokretanje bezicne veze

if ( status != WL_CONNECTED) { // Ako veza nije uspostavljena

Serial.println("Neuspjelo povezivanje"); // Prikazi poruku

while(true); // Beskonacno cekanje

}

else { // U suprotnom ako je veza uspostavljena

Serial.println("Povezan na mrezu"); // Prikazi poruku

}

}

void loop() {

// Ne radi nista

}

Izvorni kod 4.1: Primjer Arduino programa za povezivanje na WPA2 bežicnu mrežu

i poznato razvojno okruženje pod nazivom Eclipse IDE da radi s Arduino uredajima,

te opcenito s AVR mikrokontrolerima.

4.4.1. Arduino IDE

U sklopu Arduino projekta postoji i integrirano razvojno okruženje, pod imenom

Arduino IDE, cije je sucelje prikazano na slici 4.7. Rijec je o aplikaciji namijenjenoj

za razne platforme (eng. cross-platform) koja je pisana u programskom jeziku Java

te razvijena iz integriranih razvojnih okruženja za projekte Processing i Wiring. Ovo

razvojno okruženje podržava programske jezike C i C++, koristeci specijalizirana pra-

vila za organizaciju koda. Samo sucelje je veoma jednostavno i intuitivno, kako bi

pocetnicima i onima koji nisu previše upoznati s razvojem softvera, olakšalo pisanje

41

i prevodenje koda za Arduino uredaje. Okruženje se sastoji od uredivaca koda (eng.

code editor) sa znacajkama kao što su bojanje sintakse (eng. syntax highlighting),

automatskog zatvaranja zagrada (eng. brace matching) te automatskog poravnavanja.

Kada je kod napisan, Arduino IDE omogucuje prevodenje koda i prebacivanje istog na

Arduino uredaj putem jednog klika. Jedan program napisan za Arduino uredaj u ovom

okruženju se naziva skica (eng. sketch). Može se sastojati i od više povezanih datoteka

(ukljucujuci i zaglavlja, odnosno .c/.cpp i .h datoteke), primjerice da kod objektnog

oblikovanja svaki par .cpp i .h datoteke predstavlja jednu klasu. U samom okruženju

se nalaze brojni primjeri napisanog koda, koje je potrebno samo prevesti i prebaciti na

plocu za rad. Korisna opcija je i ugraden serijski monitor za pracenje ispisa na serijsku

vezu. Takoder, u svrhu proširenja funkcionalnosti, okruženje pruža mogucnost insta-

liranja dodatnih programskih knjižnica putem ugradenog pretraživaca za programske

knjižnice, ili iz ZIP arhive. Svaka prikladna programska knjižnica koja se instalira

dolazi i s primjerima koji se mogu prevesti i pokrenuti na Arduino uredaju. Neke od

programskih knjižnica su i predinstalirane, kao što je primjerice programska knjižnica

naziva Wiring koja pruža mnoge ulazno-izlazne procedure.

Slika 4.7: Prikaz izgleda sucelja Arduino IDE razvojnog okruženja

42

4.4.2. Jednostavan primjer Arduino programa

Izvorni kod 4.2 prikazuje jednostavan primjer programa napisanog za Arduino ure-

daj, koji pali i gasi svijetlecu diodu u periodu od 1 sekunde. Ovaj primjer je prikladan

zbog toga što vecina Arduino uredaja na sebi ima ugradenu svijetlecu diodu i pripada-

juci otpornik, koji su serijski povezani izmedu pina 13 i mase, pa za izvršavanje ovog

programa nije potreban nikakav dodatni hardver. Štoviše, nakon izrade Arduino ure-

daja, proizvodac najcešce presnimi ovaj kod na plocu tako da se odmah može testirati

ispravnost Arduino uredaja nakon kupnje.

#define LED_PIN 13 // Broj pina na koji je LED dioda spojena

void setup() {

pinMode(LED_PIN, OUTPUT); // Postavljanje pina kao izlaznog

}

void loop() {

digitalWrite(LED_PIN, HIGH); // Paljenje LED diode

delay(1000); // Cekanje 1 sekunde (1000 ms)

digitalWrite(LED_PIN, LOW); // Gasenje LED diode

delay(1000); // Cekanje 1 sekunde

}

Izvorni kod 4.2: Primjer Arduino programa za paljenje i gašenje LED diode

Na danom primjeru koda se može vidjeti da se svaki Arduino program, odnosno

skica, sastoji od dvije glavne funkcije koje moraju biti definirane, te se prevode i po-

vezuju s glavnom funkcijom u C/C++ programskom jeziku main() u izvršni ciklicki

program. Te dvije funkcije su redom:

– setup() - funkcija koja se izvršava jednom, pri pokretanju Arduino uredaja, te

se koristi za inicijalizaciju i definiranje raznih parametara, kao što je primjerice

inicijalizacija serijske veze, povezivanje na mrežu, postavljanje ulazno-izlaznih

pinova i sucelja, postavljanje pocetnih vrijednosti itd.

– loop() - funkcija koja se neprestano, u beskonacnoj petlji, poziva dok je god

Arduino uredaj ukljucen, i prvi se put poziva nakon izvršavanja funkcije setup()

43

5. Implementacija na uredaju Arduino

U svrhu demonstracije rada protokola MQTT i CoAP, koji su opisani u ovom radu,

implementiran je jednostavan sustav na uredaju Arduino Uno, gdje se putem navede-

nih protokola može ocitavati temperatura zraka, koju mjeri uredaj Arduino, te uklju-

civati i iskljucivati svjetlece diode. U nastavku je opisana implementacija protokola,

uz primjere za svaki od protokola. Zatim je opisan korišteni hardver, a naposlijetku je

prikazan rad sustava.

5.1. Implementacija protokola MQTT

5.1.1. Mosquitto posrednik

Z implementaciju protokola MQTT je potreban posrednik (broker). Radi jednos-

tavnosti je odabran Mosquitto besplatni posrednik/poslužitelj. Ovaj posrednik pruža

testni poslužitelj koji se nalazi na adresi test.moquitto.org. Testni poslužitelj je bes-

platan i prikladan za testiranje protokola, no nije prikladan za korištenje u krajnjim

projektima, jer bilo tko može pristupiti istom te je u testnoj fazi pa se cesto ponovno

pokrece ili na sebi pokrece nekakav eksperimentalan program. Kod krajnjih proje-

kata je bolje preuzeti izvorni kod za Mosquitto brokera te ga pokrenuti na vlastitom

poslužitelju. Testni poslužitelj sluša na sljedecim portovima:

– 1883 - MQTT veza bez enkripcije

– 8883 - MQTT veza s enkripcijom

– 8884 - MQTT veza s enkripcijom, uz zahtijevanje certifikata

– 8080: - MQTT veza preko WebSockets protokola, bez enkripcije

– 8080: - MQTT veza preko WebSockets protokola, s enkripcijom

Portovi s enkripcijom podržavaju protokole TLS v1.2, v1.1 i v1.0 te x509 certifikate.

ZA komunikaciju putem porta 8884 potrebno je koristiti mosquitto.org.crt certifikat

koji se može preuzeti s njihovih službenih web stranica.

44

5.1.2. Programska knjižnica PubSubClient za protokol MQTT

Za implementaciju komunikacije putem protokola MQTT je korištena programska

knjižnica PubSubClient, koju je napisao Nick O’Leary te objavio pod MIT licencom.

Ova programska knjižnica omogucuje jednostavnu komunikaciju s poslužiteljem pu-

tem protokola MQTT, pri cemu su podržane sljedece mogucnosti:

– povezivanje na poslužitelj uz mogucnost autorizacije klijenta pomocu korisnic-

kog imena i lozinke

– postavljanje posljednje želje

– mogucnost ukljucivanja zadržavanja poruke na poslužitelju (ukljucujuci i pos-

ljednju želju)

– mogucnost slanja objave (samo s kvalitetom usluge 0)

– mogucnost pretplate na temu, uz mogucnost odabira kvalitete usluge 0 ili 1

U Programskoj knjižnici je moguce podesiti i pojedine parametre, kao što je mak-

simalna velicina poruke (inicijalno je 128 bajtova), duljina održavanja veze (eng. ke-

epalive) (inicijalno postavljena u 15 sekundi), te verzija MQTT protokola (inicijalno

postavljena na 3.1.1, a moguce je postaviti na 3.1). Programska knjižnica podržava

brojne Arduino uredaje, kao što su u ovom radu korišteni Arduino Uno te Arduino

YUN. Uz to podržava i brojne štitove poput Ethernet ili ovdje korištenog Wi-Fi štita.

Povezivanje na poslužitelj

Za povezivanje uredaja Arduino na poslužitelj je potrebno poslati poruku tipa CONNECT.

To se radi tako da se instancira klijent, koji u korištenoj programskoj knjižnici pripada

razredu PubSubClient. Pri tome je potrebno postaviti nekoliko parametara, putem

konstruktora ili metoda za postavljanje (eng. setter):

– Poslužitelj - adresa poslužitelja na kojeg se želi spojiti, u obliku IP adrese ili

DNS imena poslužitelja

– Port - port na kojem poslužitelj sluša

– Povratna metoda (eng. callback) (opcionalno) - metoda koja ce biti pozvana

svaki put kad klijent primi poruku od poslužitelja

– Mrežni klijent - instanca razreda Client, odnosno instanca nekog od nasli-

jedenih razreda, WiFiClient ili EthernetClient, ovisno o nacinu pove-

zivanja na mrežu, pomocu kojeg ce programska knjižnica slati i primati poruke

45

– Tok podataka (eng. stream) (opcionalno) - instanca razreda Stream, za po-

hranu primljenih poruka

Zatim je potrebno pozvati metodu connect() nad instancom razreda PubSubC-

lient, koja poslužitelju šalje poruku tipa CONNECT. Nužan parametar je clientID,

a rijec je o nizu znakova koji predstavljaju jedinstveni identifikator ili ime klijenta. Op-

cionalno je moguce unijeti korisnicko ime i lozinku, ako poslužitelj zahtjeva prijavu.

Takoder, moguce je opcionalno poslati posljednju želju tako da se unesu parametri kao

što su tema u koju ce se slati ta poruka, sadržaj poruke, kvaliteta usluge poruke, te

hoce li poslužitelj pohraniti i zadržati posljednju želju ili ne. Nakon što je veza ostva-

rena, pomocu metoda connected() i state() je moguce provjeriti da li je klijent

povezan s poslužiteljem te u kojem se trenutno stanju nalazi. Takoder je potrebno u

beskonacnoj petlji pozivati metodu loop(), koja omogucava primanje i obradu do-

laznih poruka te održavanje veze s poslužiteljem.

Pretplata na teme

Za primanje poruka potrebno se pretplatiti na jednu ili više tema, za koje se želi

primati poruke. Za to je zaslužna metoda subscribe(), koja kao parametar prima

naziv teme u obliku niza znakova, te opcionalno kvalitetu usluge (0 ili 1). Analogno

tome, metoda unsubscribe() se koristi za otkazivanje pretplate na temu te kao

parametar takoder prima naziv temu.

Kad pristigne poruka na uredaj Arduino, poziva se tako zvana povratna metoda

(eng. callback), koju je potrebno implementirati te pridružiti klijentu prilikom njego-

vog instanciranja. Toj metodi se prosljeduju tri parametra: naziv teme, sadržaj poruke

te duljina sadržaja, a s primljenim vrijednostima se onda mogu poduzeti proizvoljne

akcije. Alternativno, moguce je koristiti tok podataka (eng. stream) za pohranu pristi-

glih poruka.

Slanje objava

Za slanje objava se koristi metoda publish(). Potrebno je kao parametar predati

niz znakova koji sadrži naziv teme u koju se šalje te sadržaj poruke koji može biti

niz znakova ili niz bajtova. U slucaju niza bajtova je potrebno unijeti i duljinu niza.

Opcionalno je moguce postaviti i opciju da poslužitelj pohrani i zadrži poruku.

46

Primjer programa

Izvorni kod 5.1 prikazuje primjer programa koji se povezuje na prethodno opisani

testni poslužitelj Mosquitto, te se pretplacuje na temu /test/tema1, a po primljenoj

poruci istu šalje na temu /test/tema2.

#include <WiFi.h>

#include <PubSubClient.h>

char ssid[] = "Naziv mreze"; // Naziv bezicne mreze

char pass[] = "Lozinka"; // Lozinka za mrezu

char broker[] = "test.mosquitto.org"; // Posrednik

#define PORT 1883

WiFiClient WifiClient; // Klijent za bezicnu vezu

// Povratna funkcija

void callback(char* tema, byte* sadrzaj, unsigned int duljina);

// Inicijalizacija MQTT klijenta

PubSubClient MQTT_Klijent(broker, PORT, callback, WifiClient);

// Povratna funkcija

void callback(char* tema, byte* sadrzaj, unsigned int duljina) {}

// Potrebno je napraviti kopiju

byte* kopija = (byte*)malloc(duljina + 9); // Alociranje memorije

memcpy(kopija,"Arduino: ",9); // Ubacivanje teksta

memcpy(kopija + 9,sadrzaj,duljina); // Kopiranje pristigle poruke

MQTT_Klijent.publish("test/tema2", kopija, (duljina + 9)); //

Posalji objavu

free(kopija); // Oslobadanje memorije*/

}

void setup() {

int status = WiFi.begin(ssid, pass); // Povezivanje na mrezu

if (status != WL_CONNECTED) // Ako konekcija nije uspjela

while(true); // Cekaj u beskonacnost

// Spajanje na posrednika

if (!MQTT_Klijent.connect("KlijentTest"))

47

while(true); // Ako nije uspjelo, cekaj u beskonacnost

MQTT_Klijent.subscribe("test/tema1"); // Pretplata

}

void loop() {

MQTT_Klijent.loop(); // Ponavljaj u beskonacnost

}

Izvorni kod 5.1: Primjer Arduino programa za jednostavnu MQTT vezu

5.1.3. Aplikacija Mosquitto za operacijski sustav Linux

Kako bi mogli poslati neku poruku Arduino uredaju te primiti ono što uredaj poša-

lje, potrebno je imati još barem jednog klijenta. Radi jednostavnosti je za to odabrana

aplikacija Mosquitto za operacijski sustav Linux. Za potrebe implementacije ovog

rada, korišten je operacijski sustav Ubuntu, na kojem je potrebno instalirati klijenta

tako da se u komandnoj liniji (eng. terminal) unese sljedeca naredba:

sudo apt-get install mosquitto

Jednom kada je aplikacija instalirana, moguce je pretplatiti se na teme ili slati

objave. Za pretplatu na teme se koristi naredba mosquitto_sub, a za objavu na-

redba mosquitto_pub. Kod pretplate komandna linija bude blokirana sve dok se

želi primati poruke s pretplacene teme. Kako bi se istovremeno moglo primati i slati,

potrebno je otvoriti dvije komandne linije. Na slici 5.1 je prikazan primjer komuni-

kacije s uredajem Arduino na kojem se pokrece prethodno opisani primjer. U jednom

prozoru komandne linije potrebno je pretplatiti se na temu test/temaB s naredbom:

mosquitto_sub -h test.mosquitto.org -t test/temaB -v

U drugom se prozoru komandne linije šalje poruka u temu test/temaA sa sljedecom

naredbom:

mosquitto-pub -h test.mosquitto.org -t test/temaA -m "Hello World"

48

Slika 5.1: Prikaz komunikacije s Arduino uredajem pomocu aplikacije Mosquitto

5.2. Implementacija protokola CoAP

5.2.1. Programska knjižnica CoAP Arduino

Za implementaciju protokola CoAP na uredaju Arduino je korištena programska

knjižnica CoAP Arduino, koju je napisao Hirotaka Niisato te objavio pod MIT licen-

com. Ova programska knjižnica implementira neke od mogucnosti protokola CoAP te

omogucava ostvarenje jednostavne komunikacije putem istog. Potrebno je definirati

povratne metode za primanje poruka i pridružiti ih poslužitelju (opisano u poglavlju

5.2.1). Zatim je potrebno pokrenuti poslužitelj pomocu metode start(). Napos-

ljetku, potrebno je u beskonacnoj petlji pozivati metodu loop() cija je zadaca prima-

nje poruka.

Slanje poruka

Za slanje poruka se koristi metoda send(), koja kao parametre prima IP adresu

i port poslužitelja, URI na koji se šalje, tip poruke, tip zahtjeva (metoda), duljinu i

sadržaj tokena te sadržaj koji se šalje (eng. payload) i njegovu duljinu. Identifikator

poruke se generira nasumicno, pomocu metode rand().

Dodatno, tu je metoda sendResponse() za slanje odgovora na primljene zah-

tjeve. Obavezni parametri su IP adresa i port poslužitelja te identifikator poruke, a

dodatno se mogu unijeti i sadržaj koji se šalje te njegova duljina, tip odgovora na zah-

tjev (eng. response code), tip sadržaja koji se šalje te vrijednost i duljina tokena.

49

Naposljetku, postoje i dvije metode za jednostavnije slanje PUT i GET zahtjeva.

Metoda get() kao parametre prima IP adresu i port poslužitelja te URI kojem se

pristupa. Analogno tome, metoda put() prima iste parametre kao i prethodno opisana

metoda, uz dodatak sadržaja koji se šalje. Opcionalno se može kao parametar predati i

duljina sadržaja poruke.

Primanje poruka

Kao i kod protokola MQTT, potrebno je definirati povratnu metodu koja se poziva

kod primitka poruke. Medutim, kod protokola CoAP postoje dvije vrste primljenih po-

ruka. Jedna vrsta je odgovor, koji se primjerice dobije nakon GET zahtjeva. Drugi tip

je sam zahtjev, koji neki drugi klijent šalje, i on je vezan za URI. Stoga je potrebno de-

finirati najmanje dvije povratne metode. Zatim se povratna metoda za primanje odgo-

vora pridružuje poslužitelju pomocu metode response(), koja kao ulazni parametar

prima ime funkcije. Povratna metoda za primanje zahtjeva se poslužitelju pridružuje

pomocu metode server() koja kao ulazne parametre prima ime povratne metode te

URI, za koji se veže ta povratna metoda. Tako je moguce zadati više povratnih metoda

i svaku vezati za odredeni URI.

Povratnu metodu je potrebno napisati. Ona kao parametre prima CoAP paket te

IP adresu i port, s koje je zahtjev ili odgovor došao. Iz CoAP paketa je zatim moguce

izvuci podatke, kao što su tip zahtjeva, kodna oznaka poruke, duljina i sadržaj tokena,

duljina i sadržaj poruke (eng. payload), identifikator poruke te opcije. Opcije su po-

hranjene kao polje, uz pripadnu varijablu s brojem opcija, a za svaku opciju se može

dohvatiti njezin broj, duljina vrijednosti opcije te sama vrijednost opcije.

Primjer programa

Izvorni kod 5.2 prikazuje primjer programa koji istovremeno služi kao CoAP kli-

jent i poslužitelj. Program ceka na poruku koju primi a zatim sadržaj iz te poruke šalje

natrag na poslužitelj metodom PUT. URI na kojem ceka poruku i URI na koji šalje

poruku su isti, a u pitanju je URI test.

#include <WiFi.h> // Programska knjiznica za Wi-Fi

#include <WiFiUdp.h> // Programska knjiznica za UDP putem Wi-Fi

#include "coap.h" // Programska knjiznjica Arduino CoAP

char ssid[] = "NazivMreze"; // Naziv bezicne mreze

char pass[] = "Lozinka"; // Lozinka za mrezu

50

WiFiUDP UDP_Klijent; // Instanca razreda za UDP vezu putem Wi-Fi

Coap CoAP_Klijent(UDP_Klijent); // Instanca razreda za CoAP

komunikaciju

// Povratna funkcija koja se poziva kod primitka zahtjeva od

posluzitelja

void Callback_Request(CoapPacket &packet, IPAddress ip, int port) {

CoAP_Klijent.sendResponse(ip, port, packet.messageid, NULL, 0,

COAP_VALID, COAP_NONE, packet.token, packet.tokenlen);

char p[packet.payloadlen + 1];

memcpy(p, packet.payload, packet.payloadlen);

p[packet.payloadlen] = NULL;

CoAP_Klijent.put(ip, 5683, "test", p);

}

void setup() {

int status = WiFi.begin(ssid, pass); // Povezivanje na mrezu

while (status != WL_CONNECTED); // Cekaj dok nije povezan

CoAP_Klijent.server(Callback_Request, "test"); // Postavi povratnu

funkciju za URI "test"

CoAP_Klijent.start(); // Pokreni CoAP klijenta/posluzitelja

}

void loop() {

CoAP_Klijent.loop(); // Ponavljaj u beskonacnost

}

Izvorni kod 5.2: Primjer Arduino programa za jednostavnu CoAP vezu

5.2.2. Racunalna aplikacija za komunikaciju putem protokola CoAP

Kako bi se mogao testirati protokol CoAP na uredaju Arduino, potrebno je imati

još jedan cvor koji ce slati zahtjeve i odgovore na uredaj Arduino te primati zahtjeve

i odgovore koji isti pošalje. U svrhu toga, napisana je jednostavna aplikacija za racu-

nalo, u programskom jeziku C#, koristeci programsku knjižnicu CoAP.NET. Buduci da

pisanje aplikacija za racunalo nije tema ovog rada, detalji o implementaciji aplikacije

nece biti opisani. Aplikacija podržava mogucnosti nužne za rad sa svim primjerima u

51

sklopu ovog rada, kao što su:

– Dohvacanje trenutne temperature s uredaja Arduino

– Ukljucivanje i iskljucivanje svjetlece diode na uredaju Arduino

– Postavljanje intenziteta svjetlosti svjetlece diode na uredaju Arduino

– Slanje proizvoljnog teksta na uredaj Arduino

– Dohvacanje teksta s uredaja Arduino

Slika 5.2 prikazuje korištenje aplikacije s primjerom programskog koda iz poglavlja

5.2.1). Unosi se proizvoljan tekst koji se potom šalje na uredaj Arduino, koji taj tekst

prima te ga šalje natrag u novoj poruci. Primitak tog teksta u aplikaciji je takoder

prikazan na slici 5.2.

Slika 5.2: Prikaz korištenja aplikacije za racunalo pri komunikaciji s uredajem Arduino

5.3. Korišteni hardver

Sustav je implementiran na Arduino Uno R3 razvojnoj ploci, koja je opisana u

poglavlju 4.2.2. Za povezivanje na mrežu je korišten štit za povezivanje na bežicnu

mrežu putem standarda Wi-Fi, takoder opisan u poglavlju 4.3.1. Osim toga, korišten

je i senzor za temperaturu i vlažnost zraka, te dvije svjetlece diode (eng. LED - Light-

emitting diode).

5.3.1. Senzor za temperaturu i vlažnost zraka

Pri implementaciji je korišten modul iz kolekcije pod nazivom Grove, tvrtke Se-

eedStudio, koji na sebi sadrži DHT11 senzor za mjerenje temperature i vlažnosti zraka.

Ovaj senzor je prigodan za primjene opce namjene, te najbolje radi pri temperaturama

od 0 do 50 stupnjeva Celzijusa, te za vlažnost zraka od 20 % do 50 %. Napaja se s

52

naponom od 3.3 V do 5 V, preciznost mjerenja temperature je +- 2 stupnjeva Celzijusa,

dok je preciznost mjerenja vlažnosti zraka +- 5 %. Osjetljivost je 1 stupanj Celzijus za

temperaturu, odnosno 1 % za vlažnost zraka, a period mjerenja iznosi 2 sekunde. Za

ovaj senzor postoji podrška za uredaje Arduino, Raspberry Pi te TI LaunchPad. Senzor

je prikazan na slici 5.3.

Slika 5.3: Senzor DHT11 za mjerenje temperature i vlažnosti zraka

5.3.2. Shema povezivanja

Shema povezivanja korištenog hardvera je prikazana na slici 5.4. S obzirom na to

da se na uredaju Arduino nalazi štit za bežicno povezivanje na mrežu, na slici je prika-

zano povezivanje senzora i svjetleca dioda na sam štit. Medutim, ista je konfiguracija

pinova na štitu i Arduino uredaju. Senzor za temperaturu i vlažnost zraka se povezuje

na digitalni pin, pa je za njegovo povezivanje odabran pin broj 2 na uredaju Arduino.

Zelena svjetleca dioda se takoder povezuje na digitalni izlazni pin, u ovom slucaju na

pin broj 5, dok je crvena svjetleca dioda povezana na PWM pin radi promjene intenzi-

teta svjetlosti, u ovom slucaju je to pin 9. Pri povezivanju je bilo potrebno pripaziti da

se ne povezuje na pinove koje za svoj rad koristi štit.

53

Slika 5.4: Prikaz sheme povezivanja senzora i svjetleca dioda na uredaju Arduino

5.4. Prikaz rada testne aplikacije

Kako bi se implementirana aplikacija isprobala, potrebno je priloženi kod za uredaj

Arduino prevesti i presnimiti na uredaj Arduino. Zatim je potrebno podesiti sve para-

metre, kao što su podatci za spajanje na bežicnu mrežu, podatci za MQTT posrednika

i teme za pretplatu i slanje, podatci za klijenta i URI kod protokola CoAP te mnogi

drugi. Zatim je potrebno odabrati jedan od protokola koji ce se koristiti. Neovisno o

odabranom protokolu, tri su opcije moguce:

– Dohvacanje trenutne temperature s uredaja Arduino

– Ukljucivanje i iskljucivanje zelene svjetlece diode

– Postavljanje itenziteta svjetlosti crvene svjetlece diode

54

5.4.1. Komunikacija putem protokola MQTT

Kad se odabere protokol MQTT, potrebno je na racunalu s operacijskim sustavom

Linux koristiti aplikaciju Mosquitto, koja je opisana u poglavlju 5.1.3. Zatim je po-

trebno poslati odredene poruke u teme na koje je uredaj Arduino pretplacen i koje su

definirane u izvornom kodu. Inicijalno su to teme:

– Randy/GetTemp - za slanje zahtjeva za temperaturom

– Randy/Temp - za pretplatu na primanje podataka o temperaturi

– Randy/LED1 - za ukljucivanje i iskljucivanje crvene svjetlece diode

– Randy/LED2 - za postavljanje intenziteta svjetlosti crvene svjetlece diode

Slika 5.5 prikazuje aplikaciju na racunalu, gdje se u prvom prozoru šalju radom

zahtjevi za temperaturu, ukljucivanje crvene svjetlece diode te postavljanje intenziteta

svjetlosti na vrijednost 10 za crvenu svijetlecu diodu. Na drugom prozoru se vidi do-

hvacena vrijednost temperature s uredaja Arduino.

Slika 5.5: Prikaz aplikacije Mosquitto na racunalu koja komunicira s uredajem Arduino

55

Slika 5.6 prikazuje ispis serijske veze s uredaja Arduino, gdje se vidi postupak

primanja poruka te poduzimanja potrebnih akcija.

Slika 5.6: Ispis serijske veze s uredaja Arduino pri komunikaciji putem protokola MQTT

Slika 5.7 prikazuje ukljucene svjetlece diode na uredaju Arduino.

56

Slika 5.7: Prikaz ukljucenih svjetlecih dioda na uredaju Arduino

5.4.2. Komunikacija putem protokola CoAP

Kad se odabere protokol CoAP, potrebno je na racunalu s operacijskim sustavom

Windows prevesti i pokrenuti aplikaciju napisanu u programskom alatu Visual Studio

2015, koja je priložena uz rad. Aplikacija pruža sve opcije kao i kod protokola MQTT,

što je navedeno u prethodnom poglavlju, te je njeno korištenje jednostavno i intuitivno.

Slika 5.8 prikazuje aplikaciju na racunalu, koja šalje zahtjeve uredaju Arduino. Redom

se vidi slanje zahtjeva za temperaturu, primanje odgovora i prikaz temperature, uklju-

civanje crvene svjetlece diode, postavljanje intenziteta svjetlosti zelene svjetlece diode,

iskljucivanje crvene svjetlece diode te ponovno ocitavanje temperature.

Slika 5.9 prikazuje ispis serijske veze s uredaja Arduino, gdje se vidi postupak pri-

manja poruka te poduzimanja potrebnih akcija. Upaljene svjetlece diode su prikazane

na slici 5.7 u prethodnom poglavlju.

5.5. Analiza implementacije protokola

U prethodnom poglavlju je prikazan rad testnog sustava koji koristi protokole MQTT

i CoAP. Nakon isprobavanja sustava s oba protokola, može se zakljuciti da su oba pro-

tokola prikladna i upotrebljiva za tu namjenu. Za primjer ukljucivanja svjetlecih dioda

nešto je prikladniji protokol CoAP buduci da je poruke potrebno poslati tek na zahtjev

57

Slika 5.8: Prikaz aplikacije za komunikaciju putem protokola CoAP na racunalu

Slika 5.9: Ispis serijske veze s uredaja Arduino pri komunikaciji putem protokola CoAP

korisnika. Medutim, kad bi bilo potrebno ukljucivati svjetlece diode na velikom broju

uredaja istovremeno, bilo bi jednostavnije koristiti protokol MQTT. S druge strane, kod

dohvata temperature, ako je potrebno u stvarnom vremenu osvježavati podatke, proto-

kol MQTT je prikladniji za takvu namjenu. Kod protokola CoAP klijent treba stalno

58

slati zahtjeve uredaju Arduino kako bi dobio vrijednost temperature kao odgovor. Kod

protokola MQTT se može jednostavno slati u odredenim vremenskim intervalima vri-

jednost temperature kao objavu u temu, pa se zainteresirani klijenti pretplate i dobivaju

objave, bez potrebe za eksplicitnim slanjem zahtjeva.

5.5.1. Odabir programskih knjižnica

Buduci da je rijec o otvorenom kodu (eng. open source), postoji nekoliko dostupnih

knjižnica za svaki od protokola. Medutim, ni u jednom slucaju nije rijec o službenoj

programskoj knjižnici vec o radovima pojedinaca koje su knjižnice napisali za svoje

potrebe te ih besplatno, pod MIT licencom, objavili na korištenje.

Kod protokola MQTT, besplatno su dostupne dvije programske knjižnice otvore-

nog koda; PubSubClient knjižnica koju je napisao Nick O’Leary te Adafruit knjižnica

istoimene tvrtke. Medutim, Adafruit knjižnica je prilagodena za rad sa servisom is-

toimene tvrtke, pod nazivom Adafruit IO. Zbog toga je za implementaciju odabrana

iskljucivo knjižnica PubSubClient, koja je pritom jednostavna za korištenje. Premda

ne implementira sve opcije protokola MQTT, ono što podržava bilo je sasvim dovoljno

za izradu ovog rada.

Za protokol CoAP postoje tri programske knjižnice; Arduino Microcoap koju je

napisao Toby Jaffey, Arduino-CoAP knjižnica autora pod korisnickim imenom dgian-

nakop, te CoAP knjižnica koju je napisao Hirotaka Niisato. Knjižnica Arduino-CoAP

nije bila kandidat za izradu ovog rada, jer je predvidena za rad s bežicnim protokolom

Xbee. Od preostale dvije knjižnice, odabrana je knjižnica CoAP, zbog slicnih razloga

kao i kod protokola MQTT. Rijec je o funkcionalnoj knjižnici, jednostavnoj za korište-

nje, koja ne implementira sve mogucnosti protokola CoAP no pruža sasvim dovoljno

istih za izradu ovog rada.

5.5.2. Analiza zahtjeva na resurse

S obzirom na to da se koristi uredaj Arduino za implementaciju, nije moguce eks-

plicitno odrediti opterecenje procesora pri slanju/primanju poruka. Kod mikrokontro-

lera, koji predstavlja srce uredaja Arduino, procesorska jezgra uvijek koristi citav svoj

potencijal, odnosno njezino je opterecenje uvijek maksimalno.

Sljedeci podatak koji je iznimno bitan kod ogranicenih cvorova, kao što su cvorovi

bazirani na uredajima Arduino, je zauzece memorije, kako programske tako i radne.

Rezultati korištenjem protokola MQTT, odnosno protokola CoAP, su prikazani u ta-

blici 5.1.

59

Programska memorija Radna memorija

Protokol MQTT 19,34 / 32 kB (61 %) 1263 / 2048 B (62 %)

Protokol CoAP 20,07 / 32 kB (54 %) 7098 / 2048 B (54 %)

Tablica 5.1: Prikaz zauzeca memorije uredaja Arduino ovisno o korištenom protokolu

Važno je napomenuti da je podatak o zauzecu radne memorije izracunat prije po-

kretanja programa i ukljucuje samo memoriju rezerviranu s globalnim varijablama. To

se zauzece konstantno mijenja tijekom rada programa i nije ga moguce izmjeriti. Što-

više, kad je u pitanju zauzece memorije, sve ovisi o tome na koji nacin su programske

knjižnice pisane. S obzirom na to da uredaji Arduino posjeduju male kolicine, kako

programske tako i radne memorije, podatkovni tipovi koji se koriste, kao i velicine me-

duspremnika, nacini predaje argumenata i parametara te mnoge druge stvari uvelike

utjecu na potrošnju memorijom. Uzevši tu cinjenicu u obzir, eksplicitna usporedba

zauzeca memorije nije prikladna za usporedbu samih protokola.

Posljednji od podataka koji bi valjalo analizirati je kašnjenje mreže te trajanje slanja

poruka. Medutim, pri izradi ovog rada je korištena bežicna veza na temelju standarda

Wi-Fi, te kašnjenja i vremena slanja uvelike ovise o samoj kvaliteti bežicne veze pa je

zakljucak da takva analiza ne bi bila odviše korisna. Ono što je važno napomenuti je da

se kod oba protokola komunikacija odvija gotovo trenutno, što znaci da se pritiskom

na tipku za slanje na racunalu trenutno pali svjetleca dioda na uredaju Arduino pa bi i

kod analize razlike bile minimalne.

5.5.3. Velicina poruke

Cilj je za istu funkcionalnost poslati što manju kolicinu poruke pa valja analizirati

i taj podatak. Sadržaj je uvijek iste velicine, neovisno o protokolu pa je izuzet iz

analize.. Drugi podatak koji se šalje je naziv teme kod protokola MQTT odnosno

URI kod protokola CoAP, koji su takoder izuzeti jer su ti nazivi varijabilni i mogu se

podesiti da kod oba protokola budu iste velicine. Velicina zaglavlja protokola MQTT

iznosi 2 bajta, a kod protokola CoAP 4 bajta uz nužnost slanja tokena, koji može biti

duljine od 0 do 8 bajtova. Kod oboje protokola još postoje i dodatne opcije koje mogu

i ne moraju biti u poruci pa nisu uzete u obzir. Sudeci po zaglavlju, protokol CoAP ima

nešto vecu kolicinu dodatnih informacija koje se nadodaju na poruku, no razlika nije

toliko velika, da bi na temelju toga protokol MQTT mogao odnijeti uvjerljivu pobjedu.

60

6. Zakljucak

U ovom radu usporedena su dva protokola prikladna za korištenje na ogranicenim

cvorovima u mreži Interneta stvari, pod nazivima MQTT i CoAP. Oba protokola imaju

svoje prednosti i nedostatke, a odabir protokola ovisi o podrucju primjene. MQTT

protokol je prikladan za korištenje kod medusobne komunikacije više cvorova (eng.

many-to-many), te omogucava prijenos poruka medu više klijenata putem središnjeg

cvora koji se naziva broker. Iako postoje mehanizmi za trajnost podataka, MQTT

najbolje funkcionira kao komunikacijska sabirnica za podatke.

S druge strane, protokol CoAP se prvenstveno koristi za komunikaciju izmedu dva

cvora (eng. one-to-one), iako podržava slanje jednog zahtjeva s poslužitelja na više

klijenata (eng. multicast). Za razliku od protokola MQTT, protokol CoAP je naj-

prikladniji za prijenos stanja te za trajnost podataka, a nešto manje za komunikaciju

baziranu na dogadajima, iako posjeduje mehanizam promatraca. Protokol CoAP za

komunikaciju koristi lakši i manje zahtjevniji protokol UDP, dok protokol MQTT ko-

risti protokol TCP za vezu s brokerom. Kad je u pitanju tip podataka koji se šalje,

protokol CoAP podržava oznacavanje tipa sadržaja, pregovaranje izmedu klijenta i

poslužitelja o tipu podataka te otkrivanje dostupnih resursa i usluga. S druge strane,

protokol MQTT ne podržava oznacavanje tipa sadržaja te se poruke mogu koristiti za

razne primjene, medutim, klijenti moraju unaprijed znati tip sadržaja.

Postoje brojni uredaji prikladni za ulogu cvorova u Internetu stvari, a u ovom radu

su opisani Arduino uredaji, kao jedni od najpoznatijih i najkorištenijih uredaja tog tipa.

Njihove brojne mogucnosti, jednostavnost korištenja, brojni dodaci u vidu hardverskih

štitova i softverskih programskih knjižnica, odlicna podrška i zajednica te niska cijena

ih cine odlicnim izborom za korištenje u Internetu stvari. U skladu s time su, u sklopu

ovog rada, su isprobana i usporedena prethodno opisana dva IoT protokola, na Arduino

uredajima.

61

LITERATURA

Andy Stanford Clark. MQTT Will Enable The Internet Of Things, Sr-

panj 2013. URL http://electronicdesign.com/embedded/

mqtt-will-enable-internet-things. Pristupljeno 21.05.2016.

Arduino.cc. Arduino, Lipanj 2016. URL https://www.arduino.cc. Pristup-

ljeno 02.06.2016.

CoRE Working Group. Constrained Application Protocol (CoAP), Lipanj 2013. URL

https://tools.ietf.org/html/draft-ietf-core-coap-18. Pris-

tupljeno 22.06.2016.

GitHub. MQTT Wiki, Lipanj 2015. URL https://github.com/mqtt/mqtt.

github.io/wiki. Pristupljeno 22.05.2016.

Jack Mannino. Implementing CoAP The Secure Way, Part I: Fundamen-

tals, Svibanj 2015. URL https://nvisium.com/blog/2015/05/27/

implementing-coap-secure-way-part-i/. Pristupljeno 23.06.2016.

Toby Jaffey. MQTT and CoAP, IoT Protocols, Veljaca 2014. URL

https://eclipse.org/community/eclipse_newsletter/2014/

february/article2.php. Pristupljeno 22.05.2016.

Benjamin Leduc-Mills. What is an Arduino?, Lipanj 2016. URL https:

//learn.sparkfun.com/tutorials/what-is-an-arduino. Pristup-

ljeno 03.06.2016.

Nick O’Leary. Arduino Client for MQTT, Lipanj 2016. URL http://

pubsubclient.knolleary.net/. Pristupljeno 24.06.2016.

Roger Light. MQTT Mosquitto, Svibanj 2016. URL http://mosquitto.org/

man/mqtt-7.html. Pristupljeno 22.05.2016.

62

Ton Engbersen. MQTT-S publish/subscribe middleware for wireless sensor sys-

tems, Svibanj 2016. URL https://www.zurich.ibm.com/sys/energy/

middleware.html. Pristupljeno 24.05.2016.

Valerie Lampkin. What is MQTT and how does it work with WebSphere

MQ?, Ožujak 2012. URL https://www.ibm.com/developerworks/

mydeveloperworks/blogs/aimsupport/entry/what_is_mqtt_

and_how_does_it_work_with_websphere_mq?lang=en. Pristupljeno

22.05.2016.

Wikipedia. Arduino, Lipanj 2016. URL https://en.wikipedia.org/wiki/

Arduino. Pristupljeno 03.06.2016.

Wikipedia. Internet of Things, Travanj 2016a. URL https://en.wikipedia.

org/wiki/Internet_of_Things. Pristupljeno 28.04.2016.

Wikipedia. MQTT, Svibanj 2016b. URL https://en.wikipedia.org/wiki/

MQTT. Pristupljeno 22.05.2016.

Wikipedia. Microcontroller, Svibanj 2016. URL https://en.wikipedia.org/

wiki/Microcontroller. Pristupljeno 05.06.2016.

Wikipedia. Publish–subscribe pattern, Svibanj 2016. URL https://en.

wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern.

Pristupljeno 22.05.2016.

Xi Chen. Constrained Application Protocol for Internet of Things, Travanj

2014. URL http://www.cse.wustl.edu/~jain/cse574-14/ftp/

coap/index.html. Pristupljeno 11.06.2016.

Zach Shelby. ARM CoAP Tutorial, Svibanj 2013. URL http://www.

slideshare.net/zdshelby/coap-tutorial. Pristupljeno 25.06.2016.

63

Usporedba protokola MQTT i CoAP na uredajima Arduino

Sažetak

U današnje vrijeme mnoštvo elektronickih uredaja i objekata komunicira medu-

sobno, cineci veliku mrežu cvorova zvanu Internet stvari. S obzirom na to da pojedini

cvorovi imaju poprilicno ogranicene racunalne sustave, veoma je važna optimizacija

prilikom projektiranja sustava, pri cemu je komunikacija jedna od najbitnijih stavki.

Uzevši u obzir cinjenicu da mnoštvo cvorova komunicira putem veoma ogranicenih

mreža, s niskom propusnošcu i cestim ispadanjima, pojavila se potreba za implementa-

cijom novih protokola za komunikaciju, koji su laganiji te prilagodeniji za rad u takvim

mrežama. U sklopu ovog rada opisana su dva takva protokola imena MQTT i CoAP,

ukljucujuci njihovu primjenu na uredajima Arduino, koji su prikladni za korištenje kao

cvorovi u Internetu stvari.

Kljucne rijeci: MQTT, CoAP, protokoli, Arduino, Internet Stvari

A Comparison of MQTT and CoAP Protocols on Arduino Devices

Abstract

Lots of electronic devices and objects nowadays are communicating together, as

a part of a large network of nodes called Internet of things. Some of these nodes

have very constrained computing systems so optimization during system development

is crucial. The most important aspect of a system is communication between nodes.

Since lots of nodes have very limited computing power and are operating on very cons-

trained networks, with low bandwidth and frequent drop-outs, development of new and

lightweight protocols suitable for these kind of networks was essential. Two protocols

named MQTT and CoAP are described in this thesis, including their application on

IoT friendly devices called Arduino.

Keywords: MQTT, CoAP, protocols, Arduino, Internet of Things