fbpx

Blog

Home   /   general   /   Internet of Things i MQTT protokol
internet of things

Internet of Things i MQTT protokol

Nekad naučna fantastika – sad realnost

Prije deset godina ideja o daljinskom kontrolisanju klima uređaja, svijetala u stanu, bojlera, sistema za zaštitu kuće i mnogih drugih uređaja pomoću mobilnog telefona je zvučala poput naučne fantastike. Međutim, danas je to naša stvarnost. Predviđa se da će do 2021. godine tržište ,,pametnih kuća” dostići vrijednost od 45 milijardi američkih dolara. Sjedinjene Američke Države imaju najveći trend porasta, a prate ih Japan i Njemačka.

Paradigma koja se neizostavno spominje uz pojam ,,pametna kuća” jeste Internet of Things (skr IoT). IoT predstavlja mrežu fizičkih uređaja, vozila, kućnih aparata, i raznih drugih uređaja opremljenih elektronikom, softverom, senzorima i aktuatorima, koji su umreženi i na taj način međusobno razmjenjuju podatke. Predviđa se da će broj umreženih uređaja unutar IoT paradigme preći 50 milijardi.

Internet of Things predstavlja trenutno jedan od vodećih trendova u IT industriji, koji će na našim prostorima tek da zaživi i nađe primjenu.

 

mind blown reakcija

Internet of Things

Pojam ”Internet of things” ili IoT je nastao 1999. godine, na univerzitetu MIT (Massachusetts institute of Technology) od strane Kevin Ashton-a. Posljednjih godina ovo je jedan od najvećih trendova u svijetu informacionih tehnologija. IoT omogućava objektima da budu kontrolisani iz daljine preko postojeće mrežne infrastrukture, što pruža mogućnost za direktniju integraciju fizičkog svijeta u kompjuterski zasnovane sisteme. Rezultat toga je poboljšana efikasnost, preciznost i ekonomski benefit uz smanjenje ljudske intervencije. Stvari (Things) u IoT smislu se mogu odnositi na širok spektar uređaja kao što su implanti za praćenje rada srca, automobili sa ugrađenim senzorima, kamere koje prenose uživo kretanje divljih životinja, uređaji za pametne kuće itd. One zapravo predstavljaju nerazdvojivu mješavinu hardvera, softvera, podataka i servisa. Ovi uređaji prikupljaju korisne podatke uz pomoć različitih postojećih tehnologija, a zatim autonomno razmjenjuju podatke sa drugim uređajima u mreži.

Polja primjene su: pametne kuće, proizvodnja, agrikultura, ušteda energije, nadgledanje životne sredine, medicina…

Arhitektura

U zavisnosti od polja primjene zavisi i sama arhitektura IoT sistema. Primjer jedne arhitekture sastoji se iz 4 dijela: pametnog uređaja, gateway-a (Raspberry Pi), cloud servisa i korisničke aplikacije.

arhitektura internet of things
Slika 1 – Arhitektura IoT sistema

 

  • Pametni uređaj može biti senzor koji očitava neke vrijednosti, a može biti i lampa kojom se upravlja putem interneta. Senzori su uređaji koji mjere fizičke veličine i konvertuju ih u signale koji su čitljivi posmatraču ili instrumentu.
  • Gateway je uređaj koji se nalazi u čvoru računarske mreže i služi za komuniciranje sa nekom drugom mrežom, koja koristi isti ili neki drugi mrežni protokol. On prikuplja informacije od senzora koji su povezani na ploču i prosljeđuje ih u cloud. Takođe prima i informacije sa cloud-a i prosljeđuje ih na uređaje.
  • Cloud servis, server, prima informacije od gateway-a, obrađuje ih i prosljeđuje dalje korisničkoj aplikaciji i obratno. On predstavlja centralnu komponentu arhitekture i ima ulogu poslužilaca u komunikaciji.
  • Korisnička aplikacija je aplikacija koju koristi krajnji korisnik za: upravljanje pametnim uređajima, prikaz podataka dobijenih od senzora, prikaz statistika i izvještaja, analizu podataka, i slično. Ona ne komunicira direktno sa senzorima, već komunikacija ide preko cloud servisa.

 

MQTT protokol

Jedan od najvažnijih djelova IoT sistema predstavljaju protokoli za razmjenu podataka između uređaja.

MQTT (Message Queuing Telemetry Transport) je izuzetno jednostavan i lagan protokol za razmjenu poruka zasnovan na principu objavi-pretplati (publish-subscribe). Dizajniran je za ograničene uređaje, nepouzdane mreže i mreže niskog propusnog opsega. Osnovno načeo dizajna jeste minimizacija zahtjeva mrežnog propusnog opsega i uređaja a da se u isto vrijeme obezbijedi pouzdanost i određeni stepen sigurnosti isporuke. Ispostavilo se da su ova načela učinila protokol idealnim za IoT svijet i za mobilne aplikacije sa ograničenom baterijom i mrežnim protokom.

Razvili su ga 1999. godine Andy Stanford Clark (IBM) i Arlen Nipper (Eurotech) da bi pratili naftovod u pustinji. Bio im je potreban protokol koji bi obezbijedio efikasnu brzinu prenosa podataka uz malu potrošnju baterije i ekonomičnost.

 

speed gif

 

Ovaj protokol sa svojom objavi-preplati arhitekturom se pokazao lakšim i ekonomičnijim od HTTP protokola sa zahtjev-odgovor (request-response) modelom. Objavi-preplati model omogućava klijentima da objavljuju poruke bez brige o njihovim konačnim destinacijama. To za njih obavlja MQTT posrednik – broker, na osnovu klijentskih preplata. MQTT koristi standardne portove: 1883 port za MQTT TCP konekciju, odnosno 8883 port za MQTT TLS konekciju. Nalazi se na vrhu TCP/IP protokola. Odlikuje ga i mala veličina fiksnog zaglavlja od svega 2 bajta što dodatno smanjuje mrežno opterećenje.

Protokol funkcioniše na sljedeći način: ako su klijenti zainteresovani za određenu temu oni će se pretplatiti ili objavljivati neki sadržaj na tu temu. Centralna komponenta ovog protokola, broker, igra ulogu poslužioca. Sve poruke dolaze do njega i on ih preusmjerava samo onim klijentima koji su se pretplatili na temu određene poruke.

U našem primjeru ovaj protokol je korišćen zbog svoje otvorenosti, sigurnosti, jednostavne arhitekture i dostupnosti odgovarajućih Python-ovih biblioteka.

Objavi-pretplati koncept

Objavi-pretplati model je alternativa tradicionalnom klijent-server modelu, gdje klijent komunicira direktno sa krajnjom tačkom. Objavi-pretplati razdvaja klijenta, koji šalje određenu poruku (publisher) od drugog ili više klijenata koji primaju poruku (subscriber). Ovo znači da publisher i subscriber ne znaju ništa o međusobnom postojanju. Između njih postoji treća komponenta, broker koji je poznat i publisher-u i subscriber-u koji filtrira sve dolazne poruke i distribuira ih shodno tome.

 

grafikon objasnjavanja mqqt
Slika 3.1 Objavi-preplatiti arhitektura, izvor: hivemq.com

 

Glavni aspect u objavi-pretplati modelu je razdvajanje publisher-a od subscriber-a koje se može razlikovati u više dimenzija:

  • Prostorna dimenzija – Ne bi trebalo da se publisher i subscriber međusobno poznaju (npr. po IP adresi i portu).
  • Vremenska dimenzija – Publisher i subscriber ne moraju da budu aktivni u isto vrijeme.
  • Sinhronizacijska dimenzija – Operacije na obje komponente se ne zaustavljaju tokom objavljivanja ili prijema.

 

Objavi pretplati model takođe pruža veću skalabilnost od tradicionalnog klijent-server pristupa. Zbog toga operacije na broker-u moraju biti visoko paralelizovane. Takođe, često keširanje i inteligentno usmjeravanje poruka su odlučujući za poboljšanje skalabilnosti.

Definitivno veliki izazov za publish-subscrib model predstavljaja skaliranje velikog broja konkecija. Ovaj problem se može prevazići korištenjem klasterizovanih brokerskih čvorova kako bi se distribuiralo opterećenje preko više pojedinačnih servera sa balanserima opterećenja.

Filtriranje poruka se temelji na jednom od tri kriterijuma:

  • Tema – Ovo filtriranje je zasnovano na subjektu ili temi koja predstavlja sastavni dio svake poruke. Klijent primalac se pretplaćuje na teme za koje je zainteresovan, a od brokera dobija sve poruke bazirane na pretplaćenim temama. Teme generalno predstavljaju stringove sa hijerarhijskom strukturom, koje omogućavaju filtriranje zasnovano na ograničenom broju izraza.
  • Sadržaj – Ovo filtriranje se zasniva na određenom sadržajnom filteru, odnosno jeziku. Loša strana ovog filtriranja je to što sadržaj poruke mora biti unaprijed poznat i ne može biti šifrovan ili promijenjen.
  • Tip – Ovo filtriranje je zasnovano na tipu odnosno klasi poruke. Pomoću ovog filtriranja pretplatnici mogu da primaju sve poruke određenog tipa, npr. Exception.

MQTT tema

Tema predstavlja UTF-8 enkodovan string koji koristi broker da filtrira poruke za svakog povezanog klijenta. Tema se sastoji iz jednog ili više nivoa. Svaki nivo je odvojen separatorom – kosom crtom.

mqtt tema primjer
Slika 3.2 – MQTT tema sa više nivoa, izvor: hivemq.com

 

Ne postoji potreba da klijent kreira željenu temu prije objavljivanja ili prijavljivanja na nju, jer broker prihvata svaku važeću temu bez prethodne inicijalizacije.

Svaka tema mora imati bar jedan karakter da bi bila validna i takođe može sadržati blanko karaktere. Prilikom prijavljivanja, klijent može da bira da li će da se pretplati na jednu temu, koristeći tačan naziv teme, ili na više tema istovremeno koristeći zamjenske znakove, wildcards. Wildcard se može koristiti samo prilikom pretplate na temu, nikako prilikom objavljianja. Postoje zamjenski znakovi jednog i više nivoa.

 

Single level wildcard: +

Kao što mu i samo ime kaže ovaj wildcard (+) predstavlja zamjenu za jedan nivo teme.

primjer single level wildcarada
Slika 3.3 – Single level wildcard, izvor: hivemq.com

 

Pretplata na myhome/groundfloor/+/temperature bi podudarila sve teme koje počinju sa myhome/groundfloor/, nakon čega slijedi tačno jedan nivo, jedna riječ (livingroom, bathroom, kitchen…), i koje se završavaju sa /temperature. Dakle, ova pretplata bi podudarila prvi i drugi, a ne bi treći, četvrti i peti red sa slike 3.4.

primjer za single level wildcard
Slika 3.4 – Single level wildcard primjer, izvor: hivemq.com

 

Multi-level wildcard: #

 

Za razliku od single level wildcard, multi level wildcard predstavlja zamjenu za više nivoa teme. Da bi se odredila podudaranja sa temama, obavezno je da multi level wildcard (#) bude posljednji karakter u temi, i da mu prethodi kosa crta.

primjer za multi level wildcard
Slika 3.5 – Multi Level Wildcard, izvor: hivemq.com

 

Pretplata na myhome/groundfloor/# bi podudarila sve teme koje počinju sa myhome/grounfloor/ nakon čega može da slijedi bilo šta, jedan ili više nivoa. Dakle, ova pretplata bi podudarila prvi, drugi i treći, a ne bi četvrti red sa slike 3.6.

primjer za multi level card 1
Slika 3.6 – Multi level wildcard primjer, izvor: hivemq.com

 

Uopšteno govoreći, imenovanje teme predstavlja slobodnu volju korisnika, osim što postoji jedan izuzetak. Svaka tema koja počinje znakom $ će se tretirati posebno i nije dio pretplate kada se pretplatite na #. Ovi naslovi su rezervisani za internu statistiku MQTT broker-a. Stoga korisnici neće biti u mogućnosti da objavljuje poruke na ove teme.

MQTT broker

 

MQTT broker predstavlja srce bilo kojeg protokola koji je zasnovan na publish/subscribe modelu. U zavisnosti od konkretne implementacije, broker može da istovremeno upravlja sa hiljadama povezanih MQTT klijenata. On je prvenstveno odgovoran za prijem svih poruka, njihovo filtriranje i odlučivanje kojim pretplaćenim klijentima treba proslijediti odgovarajuće poruke. Broker takođe održava sesije svih perzistentnih klijenata i zadužen je za autentifikaciju i autorizaciju klijenata.

U većini slučajeva, broker je proširiv, što omogućava laku integraciju prilagođenih, custom autentifikacija, autorizacija i integracija u backend sistemima. Posebno je bitan aspekt integracija, jer je često broker komponenta koja je direktno izložena internetu i koja upravlja velikim brojem klijenata, a zatim prenosi poruke do analitičkih sistema i sistema za obradu.

Sve u svemu, broker je centralno čvorište, koje svaka poruka treba proći. Zbog toga je važno da je visoko skalabilan, jednostavan za monitoring i otporan na ispade.

Najpoznatiji MQTT posrednici su: Mosquitto, HiveMQ, RabbitMQ, Real Small Message Broker, CloudMQTT, VenereMQ…

 

gif about writing something down

Kvalitet usluge (Quality of Service – QoS)

Kvalitet usluge je dogovor između pošiljaoca i primaoca poruke u vezi sa garancijama

dostavljanja poruke. Postoje 3 QoS nivoa u MQTT protokolu i to:

  • Najviše jednom (0)
  • Makar jednom (1)
  • Tačno jednom (2)

 

QoS 0 – Najviše jednom

Najniži nivo koji osigurava najbržu isporuku. Poruka neće biti potvrđena od strane primaoca ili sačuvana i ponovo poslata od strane pošiljaoca.

slika za primjer QoS1
Slika 3.7 – QoS 1, izvor: hivemq.com

QoS 1 – Makar jednom

Korištenjem QoS prvog nivoa, garantuje se da će poruka biti dostavljena primaocu makar jednom. Ali poruka takođe može biti primljena i više puta.

primjer za QoS 2
Slika 3.8 – QoS 2, izvor: hivemq.com

 

Pošiljalac će čuvati poruke sve dok ne dobije potvrdu u vidu PUBACK komandne poruke od primaoca. Veza uzmeđu PUBLISH i PUBACK se potvrđuje upoređivanjem identifikatora u svakom paketu. Ako se PUBACK ne primi u razumnom vremenu, pošiljalac će ponovo poslati PUBLISH poruku. Ako primalac dobije poruku sa QoS 1, može je odmah obraditi. Na primjer, u slučaju brokera, proslijediće poruku svim svojim pretplaćenim klijentima a zatim odgovoriti sa PUBACK klijentu publisher -u.

QoS 2 – Tačno jednom

Najveći nivo, QoS 2, garantuje da će svaka poruka biti primljena tačno jednom. To je najbezbjedniji ali ujedno i najsporiji QoS nivo. Garanciju obezbjeđuje dvostruki tok između pošiljaoca i primaoca.

primjer za QoS 3
Slika 3.9 – QoS 3, izvor: hivemq.com

 

Ako primalac dobije QoS 2 PUBLISH poruku, on će je proslijediti dalje, i nakon toga odgovoriti pošiljaocu sa PUBREC porukom. Primalac će sačuvati referencu na identifikator paketa sve dok ne pošalje PUBCOMP poruku pošiljaocu. Ovo je bitno da bi se spriječilo ponovno procesiranje poruke.. Kad pošiljaoc dobije PUBREC poruku, može bezbjedno da odbaci početnu objavu, PUBLISH poruku, zbog toga što zna da je primalac uspješno primio poruku. Sačuvaće PUBREC i odgovoriti sa PUBREL. Nakon što primalac dobije PUBREL, može da odbaci svako sačuvano stanje i da odgovori sa PUBCOMP. Isto važi kada primalac primi PUBCOMP. Kada se tok završi, obije strane mogu biti sigurne da je poruka uspješno dostavljena.

Kad god se paket izgubi na putu, pošiljalac je odgovoran za ponovno slanje poslednje poruke nakon određenog perioda. Ovo je tačno kada je pošiljalac MQTT klijent a takođe i kada MQTT broker šalje poruku. Primalac je odgovoran da odgovori na svaku komandnu poruku.

 

answer me gif funny

 

Zaključak je da:

  • QoS 0 treba koristiti kad imamo potpuno ili skoro stabilnu konekciju između pošiljaoca i primaoca.
  • QoS 1 treba koristiti kad nam je potrebna svaka poruka, i naš use case može da podnese duplikate.
  • QoS 2 treba koristiti kad je krucijalno za aplikaciju da poruka stigne tačno jednom.Sve poruke poslate sa QoS 1 ili QoS 2 će biti stavljene u queue za oflajn klijente, sve dok ne budu ponovo dostupni, pod pretpostavkom da ti klijenti imaju perzistentnu sesiju.

Da sumiramo

Razvojem i napretkom tehnologije na tržištu su se pojavio veliki broj tzv. “pametnih” uređaja. Sve više govori o samostalnoj komunikaciji između takvih uređaja i Internet of Things tehnologiji. Ovo područje tehnologije još nije doživjelo svoj vrhunac, ali je u velikoj ekspanziji. Hardver postaje sve jeftiniji, a informacije lako dostupne, pa je sam sistem automatizacije postao dostupan, ne samo profesionalcima nego i entuzijastima koji iz hobija osmišljavaju projekte u ovoj oblasti.

Napisao: Ilija Perović