SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Zagreb, lipanj 2016.

ZAVRŠNI RAD br. 4418

Simulirati sustav Internet stvari korištenjem

Raspberry Pi računala i EasyRadio beţičnih

modula Matej Erceg

i

ii

SADRŢAJ

1. Uvod ........................................................................................................................ 1

2. Arhitektura IoT sustava ....................................................................................... 2

2.1. Komunikacijski mediji ....................................................................................... 2

2.2. Sigurnost ............................................................................................................ 3

2.3. Fleksibilnost ....................................................................................................... 4

2.4. Adresiranje i domet ............................................................................................ 5

3. Opis korištenih ureĎaja ........................................................................................ 6

3.1. Raspberry Pi ....................................................................................................... 6

3.2. easyRadio ........................................................................................................... 7

3.3. Konfiguracija sustava ......................................................................................... 7

4. Opis IoT simulatora .............................................................................................. 9

4.1. Opći rad simulatora ............................................................................................ 9

4.2. Red za retransmisiju ......................................................................................... 12

5. Primjeri ispitnih slučajeva .................................................................................. 14

5.1. Primjer retransmisije ........................................................................................ 14

5.2. Primjer prosljeĎivanja ...................................................................................... 18

5.3. Primjer kolektora .............................................................................................. 19

6. Zaključak ............................................................................................................. 20

Literatura ...................................................................................................................... 21

Saţetak ........................................................................................................................... 22

Summary ........................................................................................................................ 22

1

1. UVOD

Internet stvari (u daljnjem tekstu prema engleskoj kratici - IoT) je koncept koji predviĎa

stvaranje mreţe fizičkih objekata koji su povezani i meĎusobno komuniciraju pomoću ugradbenih računalnih sustava. Na taj se način, izmeĎu ostaloga, omogućava razmjena i skupljanje podataka prikupljenih senzorima te upravljanje i praćenje udaljenih ureĎaja

uz povećanu efikasnost rada. Kao jedno od najbrţe rastućih polja računarstva, IoT je definitivno perspektivno polje koje vrijedi istraţiti.

Namjera ovog rada je istraţiti specifičnosti i zahtjeve arhitekture IoT sustava, te moguće

probleme kod projektiranja istih, koji uključuju pitanja sigurnosti, fleksibilnosti, skaliranja, oporavka od pogrešaka... TakoĎer, za neke od tih problema biti će

predloţena potencijalna rješenja u vidu konkretnih mehanizama ili implementacija.

Kao praktična podloga ovom razmatranju, tijekom praktičnog dijela izrade rada

ostvareno je nekoliko primjera jednostavnih IoT sustava. U tu svrhu su se, svojom pristupačnom cijenom, malim dimenzijama i praktičnošću uporabe posebno pogodnima

pokazali ureĎaji poput Raspberry Pi-a, Arduino-a, te easyRadio-a.

TakoĎer, kao temelj sustava u sloju programske podrške korišten je IoT simulator [3] dostupan na servisu GitHub, razvijen u programskom jeziku Python.

U drugom poglavlju rada napravljen je pregled problematike ostvarivanja IoT sustava, s predloţenim mogućim rješenjima. U trećem poglavlju pobliţe su opisani ureĎaji korišteni za vrijeme praktičnog dijela izrade, te njihova konfiguracija i priprema za rad. U četvrtom poglavlju dan je kratak opis korištenog simulatora uz detaljniji pregled

dodataka ugraĎenih u simulator tijekom praktičnog dijela izrade rada. Konačno, u

petom poglavlju opisano je nekoliko konkretnih konfiguracija IoT sustava ostvarenih korištenjem navedenih ureĎaja i programske podrške.

2

2. ARHITEKTURA IOT SUSTAVA

Kako bi se bolje razumjela potreba za istraţivanjem tehničkih aspekata izvedbe i

arhitekture IoT sustava, nije naodmet prvo posvjestiti značaj tog područja i navesti nekoliko gospodarskih grana na koje bi ambiciozna primjena IoT-a imala velike pozitivne učinke. Primjerice, u industrijskim pogonima i tvornicama IoT sustavi bi mogli pratiti stanje postrojenja, prikupljati podatke za analizu, dojavljivati i rješavati

slučajeve kvara, dinamički prilagoĎavati parametre rada (po nekim predviĎanjima, čak i

autonomno reagirati na fluktuacije na trţištu, ili u opskrbnim lancima) te na taj način

velikim dijelom pridonijeti automatizaciji i efikasnosti pogona.

Isto tako, IoT ureĎaji mogli bi se koristiti za upravljanje infrastrukturom, primjerice kroz brzu detekciju promjena u prometu, koordinaciju gradskih sluţbi i optimizaciju potrošnje energije, čime bi zapravo činili okosnicu tzv. Smart City sustava (pilot

projekti ovog tipa već postoje diljem svijeta).

Prema odreĎenim predviĎanjima, samo primjena IoT-a u industriji (tzv. IIoT) bi mogla unijeti promjene ravne novoj industrijskoj revoluciji i generirati gospodarsku aktivnost u vrijednosti od $12 trilijuna [1] do 2030. godine (za usporedbu, sveukupni globalni BDP u 2015. godini iznosio je $73 trilijuna).

U idućim potpoglavljima izdvojena su neka od područja problematike u arhitekturi IoT

sustava te predloţeni načini njihova rješavanja.

2.1. Komunikacijski mediji

S razvojem i prodorom IoT sustava na trţište, za očekivati je da će doći do izrazito

velikog porasta broja ureĎaja uključenih u razne IoT mreţe. Isto tako, velika većina njih

će kao prirodni medij za komunikaciju koristiti Internet, što podrazumijeva i jedinstvene

IP adrese za svaki ureĎaj. Zbog ograničenog raspona IPv4 adresa (4.3 milijarde adresa,

nasuprot procijenjenih 20-tak milijardi IoT ureĎaja do 2020.), takvi ureĎaji će morati

biti prilagoĎeni za rad s IPv6 protokolom, te će od velike vaţnosti za puno ostvarivanje

njihova potencijala biti veća podrška i prihvaćanje IPv6 u globalnim okvirima.

Kao alternativa ovome, mogu se razmatrati sustavi koji će koristiti drugačije oblike

komunikacije, primjerice serijsku radio komunikaciju. Tijekom izrade ovog rada, uspješno je iskušano jedno takvo rješenje, uz pomoć easyRadio ureĎaja (detaljniji opis u

poglavlju 3). Naravno, nedostatak ovakvog pristupa je u tome što se nije moguće

osloniti na uvrijeţene protokole i sučelja TCP/IP sloţaja, već je potrebno razraditi

vlastite protokole za pakiranje i slanje podataka.

TakoĎer, još jedno od predlaganih rješenja za problem adresabilnosti je ograničiti samu

komunikaciju izmeĎu čvorova, a time i potrebu za IP adresama, a umjesto toga omogućiti dohvatljivost svakog čvora preko jedinstvenog URI-a. U takvom scenariju bi koordinacijom, dohvatom i slanjem podataka upravljali procesorski jaki centralni posluţitelji koji bi pruţali i sučelje za interakciju s korisnicima.

3

2.2. Sigurnost

Jedna od velikih mogućnosti eksploatacije IoT sustava je u koheziji s konceptom „Big

data“. Obzirom da su IoT ureĎaji široko rasprostranjeni, te uglavnom zamišljeni kao

relativno jednostavni i nenametljivi, mogu se lako integrirati u svakodnevne predmete i okruţenje i koristiti za prikupljanje podataka o pojedincima, primjerice kroz razne oblike fitness opreme i praćenja ţivotnih navika, zatim kroz medicinske ureĎaje za

praćenje tlaka ili otkucaja srca [2], pa sve do IoT ureĎaja u trgovinama koji bi se mogli

povezati s kupčevim pametnim telefonom i pamtiti proizvode koje kupuje.

Prikupljanje, objedinjavanje i analiza velikih količina podataka o osobama i njihovim navikama dobivenih kroz razne IoT ureĎaje mogli bi se iskoristiti za slanje ciljanih

ponuda i kreiranje i prilagoĎavanje ponuĎenih sadrţaja konkretnim korisnicima. Iako takve usluge mogu biti korisne i olakšati svakodnevni ţivot, ipak otvaraju veoma osjetljivo i akutno pitanje privatnosti i sigurnosti podataka.

Primjerice, bilo kakva sigurnosna rupa ili previd u IoT sustavima, a pogotovo onima spojenim na Internet, pruţa priliku i vektor za zlonamjerno djelovanje. Kritičari IoT-a spominju mogućnosti hakiranja medicinskih ureĎaja poput pacemakera ili pak hakiranja

u sustave ugraĎene u automobile i udaljeno upravljanje kočnicama ili motorom.

Problem postaje još veći ako se uzme u obzir da IoT sustavi još nisu standardizirani, te da je razvoj sigurnosti u tom području, u smislu adresiranja specifičnih sigurnosnih problema koji se pojavljuju u komunikaciji raznolikih ureĎaja u IoT mreţi, još u

prilično ranim fazama (a sigurnosne rupe se i dalje pojavljuju i u daleko zrelijim

sustavima i protokolima, poput Facebook-a, Google Chrome-a, pa i u samom TCP/IP sloţaju). Iako radne skupine poput „Internet of Things Global Standards Initiative“, koja

je bila aktivna 2015. godine, rade na tom problemu, trţišna utakmica prisiljava

proizvoĎače da se okušaju u vlastitim rješenjima.

Dakle, iako se za ključni problem sigurnosti IoT-a još ne nazire univerzalno rješenje,

ipak se mogu poduzeti odreĎeni koraci, u vidu integracije prokušanih sigurnosnih

rješenja i protokola iz polja računarstva. Primjerice, IoT simulator korišten tijekom

izrade rada pruţa mogućnost zaštite paketa koji se šalju kroz IoT mreţu HMAC mehanizmom. HMAC sluţi za provjeru autentičnosti i integriteta podataka, a za izračun

koristi neku od kriptografskih hash funkcija. U slučaju simulatora korišten je MD5, pretpostavljeni algoritam HMAC funkcija Python modula Crypto.Hash. TakoĎer,

simulator daje i mogućnost jednostavnije enkripcije pomoću kriptografske funkcije

SHA256.

4

2.3. Fleksibilnost

Jedna od ključnih osobina dobrog IoT sustava je fleksibilnost i prilagodljivost. Realno je očekivati da će IoT mreţe biti izgraĎene od mnoštva različitih ureĎaja i komponenata

koje potječu od različitih proizvoĎača, i koje preferiraju ili su namijenjene različitim komunikacijskim medijima ili protokolima. Dok se ne postigne veća opća razina

standardizacije, ureĎaji u IoT-u morat će pruţati mogućnosti komunikacije i razmjene podataka kroz više medija, npr. ţični ili beţični pristup Internetu (Ethernet, Wi-Fi, 3G, 4G), izravna serijska radio komunikacija itd.

TakoĎer, neki ureĎaji u mreţi će se moţda češće mijenjati i nadograĎivati dok će drugi

duţe vrijeme ostajati nepromijenjeni, ili čak biti nedostupni i morati autonomno raditi na duge periode. UreĎaji koji budu posjedovali veću procesorsku snagu, ili budu u prilici lako komunicirati s kakvim klasterom centralnih posluţitelja, moći će vršiti

zahtjevnije obrade i prilagoditi se, odnosno na neki način „izaći u susret“ ureĎajima

slabijih mogućnosti koji, primjerice, zbog potrebe očuvanja baterije, mogu tek

povremeno biti aktivni i razmjenjivati podatke.

U takvim slučajevima mogući su razni mehanizmi prilagodbe, a jedan od njih, koji je razmotren i u jednostavnoj varijanti i implementiran tijekom izrade rada, je mehanizam reda za ponovno slanje poruka (retransmisiju). Pomoću takvog mehanizma, ureĎaj/čvor

moţe sačuvati poruku koju nije uspio proslijediti drugom čvoru u mreţi, bilo zbog

kvara prijenosnog medija, ispada čvora, ili samo redovitog perioda neaktivnosti čvora.

Spremljenu poruku čvor tada moţe pokušati redovno ponovno poslati nakon isteka predodreĎenog vremenskog intervala, ili npr. poslati izvanredno, odmah nakon primanja neke druge poruke od tog istog čvora, jer je u takvom slučaju drugi čvor još uvijek

vjerojatno aktivan i dostupan.

Nadalje, u slučaju da čvorovi imaju mogućnost komunikacije kroz više medija, treba

voditi računa i o mediju preko kojeg je poruka primljenja. Primjerice, ako je poruka primljena preko serijske veze, s odgovarajućim identifikatorom serijske veze,

retransmisiju (a moţda i svu komunikaciju općenito) bi isto trebalo usmjeriti preko te veze, iako je moţda pretpostavljeni ili preferirani medij za taj čvor npr. IPv4/IPv6 veza.

Valja imati na umu i da nepaţnja pri projektiranju fleksibilnih sustava, zbog samog velikog broja mogućih kombinacija ureĎaja i protokola pogoduje nastanku neočekivanih

i nepredviĎenih situacija, što potencijalno moţe kompromitirati sigurnost komunikacije

i sustava u cjelini. Dakle, potrebno je voditi računa o kompromisu izmeĎu sigurnosti i fleksibilnosti.

5

2.4. Adresiranje i domet

Još jedno pitanje koje treba spomenuti je adresiranje i domet komunikacije. Vrlo je vjerojatno da će čvorovi IoT sustava imati potrebu komunicirati s ureĎajima koje ne

mogu direktno adresirati ili im nisu u dometu. Npr. neki ureĎaj moţe duţe vrijeme

autonomno raditi i biti fizički nedostupan, dok čvor koji je zaduţen za primanje

informacija od tog čvora moţe biti podloţan zamjenjivanju, ili prenamijenjen za neku drugu svrhu, dok bi njegovu staru ulogu preuzeo neki novi čvor.

Kako bi se u takvom slučaju izbjegla potreba za rekonfiguracijom autonomnog čvora i

aţuriranjem adresa, čvor bi se mogao konfigurirati da ne šalje podatku nekom

specifičnom čvoru, već najbliţem skupljaču informacija, nazovimo ga kolektorom.

Novi čvor bi tada bio konfiguriran kao kolektor, i obliţnji čvorovi bi bili aţurirani tako

da prosljeĎuju poruke namijenjene za kolektor upravo njemu.

Još jedna zanimljiva situacija koja moţe nastupiti je u slučaju općeg odašiljanja (eng.

broadcast). Iako je opće odašiljanje zapravo neizbjeţno u slučaju beţične komunikacije,

kada je u pitanju ţična komunikacija, korištenjem npr. Ethernet-a, ona takoĎer moţe

neočekivano nastupiti u slučaju nepaţnje, npr. ako sustav čini više ureĎaja spojenih na

istu fizičku ţicu. U takvom slučaju bi poruku za koju očekujemo da će je primiti samo

jedan čvor, ipak primili svi čvorovi na ţici.

Dakle, općenito je problematično prenositi poruke kroz sustav gdje paket mora proći

više čvorova da bi stigao na odredište. Nije isključeno da je neki od čvorova na tom

putu zapravo ubačen zlonamjerno, s ciljem presretanja prometa, što nas opet dovodi do

problema sigurnosti. Slično kao i u klasičnoj komunikaciji preko Interneta, i ovdje bi se

takav problem mogao riješiti kriptiranjem, tj. pomoću mehanizama javnog i privatnog

ključa, gdje bi čvor zaključao sadrţaj poruke javnim ključem primatelja, a onda bi

jedino primatelj sadrţaj poruke mogao otključati, i to korištenjem svojeg privatnog

ključa. Isto tako, ponekad bi neki od dijelova poruke ipak mogli biti potrebni svakom čvoru na putu zbog daljnjeg usmjeravanja poruke, što bi opet sugeriralo potrebu za dvjema razinama enkripcije.

Naposljetku, moguće su i situacije kada čvor treba poslati poruku ne samo jednom čvoru nego grupi čvorova koji moţda zajedno obavljaju neku zadaću. Tada bi bilo

podesno imati sustav grupnih adresa, pa bi onda čvor mogao poslati poruku općim

odašiljanjem, a samo čvorovi koji pripadaju grupi bi mogli poruku otključati i pročitati.

6

3. OPIS KORIŠTENIH UREĐAJA

Iako su danas dostupne razne komponente mnogih proizvoĎača koje bi se mogle

iskoristiti za izgradnju IoT sustava, a neke od njih pruţaju veliku procesorsku moć i napredne mogućnosti obrade, ipak glavni faktor odabira mora biti pristupačna cijena te jednostavnost i praktičnost uporabe. Tomu je tako jer su IoT sustavi u osnovi zamišljeni

za veoma široku rasprostranjenost, pa čak i proliferaciju.

Trenutno aktualni ureĎaji koji izvrsno zadovoljavaju ovakve kriterije su Raspberry Pi i Arduino, te razni dodatni moduli poput easyRadio modula za beţičnu serijsku

komunikaciju. Tijekom izrade ovog rada korišteni su upravo Raspberry Pi i easyRadio,

te su se pokazali izvrsnim odabirom za brzu izvedbu jednostavnih IoT sustava.

3.1. Raspberry Pi

Raspberry Pi (Slika 3-1) je računalo skromnih performansi, koje unatoč tome, za veoma

pristupačnu cijenu pruţa sve funkcionalnosti koje se očekuju i od standardnih stolnih

računala, i to objedinjene u jednu tiskanu pločicu relativno malih dimenzija. Raspberry

Pi (u trenutku pisanja ovog rada aktualna je treća generacija ovih ureĎaja) sadrţi 4-jezgreni ARM-kompatibilni CPU, VideoCore GPU, koristi SD kartice za pohranu operacijskog sustava i ostalih podataka, a ima i 2 ili više USB ulaza, HDMI ulaz, te ulaz

za Ethernet, izmeĎu ostaloga. Ove karakteristike čine ga idealnim za ostvarivanje

jednostavnog čvora (sudionika) u sustavu Interneta stvari.

Slika 3-1 Raspberry Pi 2 Model B ureĎaj

7

3.2. easyRadio

UreĎaj easyRadio (Slika 3-2) omogućava serijsku beţičnu komunikaciju na kratke

udaljenosti, te predstavlja alternativno sredstvo za povezivanje ureĎaja u uvjetima kada

nije moguće ostvariti Ethernet ili Wi-Fi vezu, ili kada takve veze iz nekog razloga nisu primjerene. UreĎaj se spaja na USB ulaz računala, te se lako koristi pomoću funkcija

nekog od programskih sučelja za serijsku komunikaciju. U slučaju ovog rada za interakciju s ureĎajem korištene su funkcije pySerial paketa za progamski jezik Python.

Slika 3-2 easyRadio modul

3.3. Konfiguracija sustava

Slijedi opis nekoliko konfiguracija sustava korištenih tijekom izrade rada.

Prva korištena konfiguracija je ostvarena pomoću Raspberry Pi računalom s besplatnim Debian-baziranim operacijskim sustavom Raspbian koji je posebno dizajniran i optimiziran za Raspberry Pi računala. Na Raspberry Pi je prethodno takoĎer bila instalirana podrška za programski jezik Python (točnije, Python3), te paketi pySerial i pyCrypto, koji nisu dio pretpostavljene Python instalacije, ali su neophodni za rad simulatora. TakoĎer, na USB ulaz Raspberry Pi-a priključen je jedan easyRadio modul.

Nakon ovakve konfiguracije, preko terminala se pokreće IoT simulator. Na ovaj način bio je ostvaren jedan cjelovit čvor IoT sustava, sposoban za serijsku komunikaciju s ostalim čvorovima.

8

Kao drugi čvor u sustavu posluţilo je stolno računalo s operacijskim sustavom Ubuntu,

na kojem je takoĎer bila instalirana podrška za Python3, potrebni paketi pySerial i

pyCrypto te IoT simulator. Na USB ulaz računala priključen je drugi easyRadio modul.

Isto kao na Raspberry Pi-u, preko terminala se pokretao simulator, te je time ostvaren još jedan čvor IoT sustava. Ovakvom konfiguracijom moguće je započeti komunikaciju izmeĎu dva pokrenuta čvora, koja će se odvijati preko serijske veze koju ostvaruju dva

easyRadio modula u meĎusobnom dometu. Detalji rada sustava i testiranih ispitnih slučajeva dani su u 4. i 5. poglavlju.

Prva konfiguracija bila je prvenstveno namijenjena testiranju serijske komunikacije. U slučajevima kada čvorovi sustava koriste Ethernet vezu, dovoljno je i jedno računalo na

kojem će biti pokrenuto više terminala, gdje svi čvorovi zapravo dijele IP adresu, ali

koriste različite portove. Takva konfiguracija je i iskorištena za kasnije simulacije i testiranja, ali bi vjerojatno bila upitne iskoristivosti u ozbiljnijim situacijama rada.

TakoĎer, još jedna neostvarena mogućnost je i realiziranje veze izmeĎu čvorova

pomoću Wi-Fi tehnologije, za što bi bili potrebni odgovarajući moduli za beţičnu

komunikaciju na krajnjim računalima.

9

4. OPIS IOT SIMULATORA

Tijekom izrade rada korišten je IoT simulator prof. dr. sc. Leonarda Jelenkovića, pisan u

programskom jeziku Python. Simulator je otvorenog koda te je dostupan na adresi: https://github.com/l30nard0/dasiot.

4.1. Opći rad simulatora

Simulator je koncipiran na način da se pokreće na nekoliko različitih čvorova. Čvorovi

u najjednostavnijoj varijanti mogu biti različiti terminali pokrenuti na istom računalu,

no mogu biti i sloţenije graĎe (poput konfiguracije u prethodnom poglavlju), i tako pospješiti simuliranje i testiranje naprednijih mehanizama. Osnovno ponašanje čvorova

je isto, i odreĎeno je u Node.py modulu izvornog koda.

Dijelovi ponašanja specifični za svaki čvor definiraju se pomoću zastavica i pravila

pohranjenih u posebne .json datoteke, koje pojedini čvor učitava prilikom pokretanja.

Odabir .json datoteke, a time i ponašanja i namjene čvora, ostvaruje se u terminalu

tijekom poziva make naredbe kojom se pokreće i simulator. Prije pokretanja naredbe u

terminalu potrebno je pozicionirati se u mapu koja sadrţi izvorni kod simulatora i

.makefile datoteku. Primjer korištenja make naredbe (u ovom slučaju tc-001 je mapa koja sadrţi ţeljenu .json datoteku; sudo naredba je potrebna ako se koristi serijsko sučelje):

sudo make tc-001

Nakon pokretanja, simulator inicijalizira objekt razreda Node, koji iz dane .json datoteke čita podatke kojim inicijalizira svoje podatkovne članove. To su, izmeĎu

ostaloga, jedinstveni identifikator čvora, definicije svih veza, tj. adresa samog čvora te

pravila ponašanja čvora. TakoĎer, u .json datoteci su zapisani i podatci o adresama, tj.

vezama koje pruţaju svi ostali čvorovi u sustavu.

Pojedina veza se realizira kao primjerak razreda ConnectionClass, koji je definiran u Connection.py datoteci izvornog koda. Osnovni razred Connection nasljeĎuje nekolicina podrazreda, od kojih svaki modelira jedan od podrţanih načina

komunikacije. Primjeri su dani u tablici 4.1.

Tablica 4.1. Vrste veza

Razred Opis

IPConnection Ţična, Ethernet veza

WLsimConnection Beţična, Wi-Fi veza

SerialConnection Beţična, izravna serijska veza

10

Tijekom inicijalizacije svake od veza, koristi se funkcijsko sučelje modula socket, te se, ako je stvaranje veze uspješno obavljeno, ona dodaje u popis veza čvora (kod koji obavlja ovu funkcionalnost nalazi se u isječku koda 4.1.).

Isječak koda 4.1. Inicijalizacija veza

# initialize connections (sockets, ...)

self.conn = []

for record in self.db_find("address","id",self.id, sort="prio"):

conn = Connection.Connection ( self, record )

if conn.up:

self.conn.append ( conn )

Nakon stvaranja veza slijedi stvaranje reda za slanje poruka u kome se pohranjuju poruke pripremljene za slanje. Zadnji dio inicijalizacije je red za retransmisiju, koji je opcionalan, i zaduţen za pokušaj ponovnog slanja neuspješno poslanih poruka. Pošto je

red za retransmisiju ostvaren tijekom praktičnog dijela izrade rada, biti će nešto

detaljnije opisan u idućem potpoglavlju.

Nakon inicijalizacije, pokreće se glavna petlja čvora (isječak koda 4.2.) koja se izvodi sve dok je korisnik ne prekine, ne nastupi neka ozbiljnija nepredviĎena pogreška ili se primi poruka s naredbom za gašenje. Ovakvo ponašanje je i u skladu s namjenom

većine IoT ureĎaja, jer i oni, kao i dobar dio klasičnih ugradbenih računalnih sustava,

obavljaju odreĎenu periodičku radnju kroz nedefinirano mnogo vremena, npr.

prikupljaju informacije iz senzora. Prilikom svakog prolaska kroz petlju, čvor

provjerava da li su mu kroz neke od veza koje pruţa prema drugim čvorovima pristigle

nove poruke, i ako jesu, obraĎuje ih.

Isječak koda 4.2. Glavna petlja čvora

def run (self):

""" Per node thread function """

while not Node.shut_down:

time.sleep(0.01)

# Check for incoming messages and process them if any

for conn in self.conn:

( packet, src_addr, dest_addr, bcast ) = conn.recv()

if packet:

self.process_packet (packet,src_addr,dest_addr,bcast )

self.process_msg_queue () # process outgoing queue

self.process_retry_queue()

self.run_rules () #Check rules for time triggered events

# on exit save database

self.info ( "Node " + self.name + " shuts down")

db_save ( self.db, self.db_dir + self.name + ".json" )

11

Obrada poruke provodi se u nekoliko faza, kroz funkcije process_packet i process_message. Ukoliko je paket kriptiran, u funkciji process_packet čvor

prvo pokušava otpakirati vanjski dio poruke, koji će tipično biti HMAC enkriptiran. U slučaju uspješnog raspakiranja vanjskog dijela, čvor saznaje osnovne podatke o poruci

te moţe vidjeti da li je poruka moţda namijenjena za opće odašiljanje ili za

prosljeĎivanje. Ovisno o zastavicama kojima je inicijaliziran, čvor takvu poruku moţe

prihvatiti ili odbaciti. Ako je prihvaća, tada će pokušati raspakirati unutarnji dio poruke

u funkciji process_message, koji je takoĎer zaštićen HMAC mehanizmom. Ako je i

to uspješno obavljeno, te su podaci u unutarnjem dijelu poruke ispravni i po zastavicama prihvatljivi za čvor, on će prihvatiti poruku i konzumirati je. Kao

posljedicu prihvaćanja poruke čvor moţe stvoriti vlastitu novu poruku ili odgovor i pohraniti je u red za slanje poruka, aţurirati svoje podatke, promijeniti svoja pravila ponašanja itd. Postupak je, naravno, jednostavniji ako poruka nije kriptirana, tada je dovoljno da je poruka prihvatljiva prema zastavicama čvora.

Nakon primanja i obrade svih novih poruka slijedi obrada reda za slanje poruka kroz funkciju process_msg_queue. Tom funkcijom čvor prolazi redom kroz sve poruke koje je pripremio za slanje i pokušava ih poslati. Svaka poruka ima pridruţen odreĎen

broj adresa na koje moţe biti poslana (u jednostavnom slučaju, to mogu biti i samo različite veze prema istom čvoru), te će čvor pokušati poslati poruku na svaku od

adresa, dok jednom ne uspije. Ako slanje ni na jednu od adresa nije uspjelo, čvor

dojavljuje pogrešku, te ako je ta opcija omogućena, sprema poruku u red za

retransmisiju. Sam proces slanja preko socket sučelja odvija se u zasebnoj funkciji send_msg.

Nakon obrade reda za slanje, u funkciji process_retry_queue obraĎuje se red za

retransmisiju ukoliko čvor posjeduje takav red. Proces obrade je sličan za oba reda.

Konačni dio petlje je funkcija run_rules koja prolazi kroz niz naredbi zadanih u .json datoteci čvora. Naredbe se mogu uvelike razlikovati od čvora do čvora, te pruţaju

veliku razinu fleksibilnosti kod simulacije sustava. Jednostavna i korisna varijanta za testiranje je niz naredbi koji provjerava da li je prošao odreĎeni vremenski period, te

ako jest, pokreće stvaranje proizvoljne poruke koja će se zatim poslati nekom drugom

čvoru. Preko funkcije run_rules se definira i očekivano ponašanje čvora kod

stvaranja odgovora na primljene poruke.

U konačnici, ako čvor primi signal za gašenje, petlja se prekida, te čvor zapisuje

podatke o toj sjednici u novu .json datoteku.

12

4.2. Red za retransmisiju

Kao što je napomenuto u prijašnjim poglavljima, red za retransmisiju pohranjuje

ispravne poruke koje, zbog nekog razloga, nisu uspješno poslane na odreĎene adrese.

Razloga neuspjeha moţe biti više, od redovne neaktivnosti čvora primatelja, pa do

stvarnog ispada čvora ili grešaka u prijenosu preko komunikacijskog medija. Pogotovo

je nezgodno ako bi se zbog prvog razloga propustilo poslati neku vaţnu poruku. U

svakom slučaju, mehanizam retransmisije se tu pokazuje kao pogodno rješenje.

Red za retransmisiju zahtjeva od čvora dodatnu obradu, vrijeme i memorijski prostor,

pa tako u nekim situacijama nije primjeren. Stoga je učinjen opcionalnim, a čvor će

stvoriti red za retransmisiju ukoliko za njega postoji definicija u .json datoteci čvora.

Definicija je jednostavna, a primjer je dan u nastavku:

"retry": { "timeout": 5, "retries": 3, "multiplier": 2 }

Značenje parametara opisano je u tablici 4.2.

Tablica 4.2. Opis parametara retransmisije

Parametar Opis

timeout Inicijalno vrijeme u sekundama koje mora proteći

prije nego se poruka pokuša ponovno poslati

retries Broj pokušaja ponovnog slanja; ako toliko puta ne

uspije retransmisija, poruka se briše iz reda za

retransmisiju

multiplier Faktor kojim se mnoţi početni timeout nakon

svakog neuspješnog pokušaja retransmisije

Kao što se moţe zaključiti iz opisa parametara, da bi se izbjeglo nepotrebno zakrčivanje

veze učestalim pokušajima retransmisije, svaka iduća retransmisija ima sve veći

vremenski odmak prije idućeg slanja.

Funkcija kojom se obraĎuje red za retransmisiju dana je u nastavku.

Isječak koda 4.3. Obrada reda za retransmisiju

def process_retry_queue (self):

"""Try to resend valid unsent messages"""

for qmsg in self.retry_queue[:]:

#if timeout has elapsed, try sending again

if qmsg["initial_time"] + qmsg["timeout"] <=time.time():

if qmsg["retries"] <= 0:

self.error("msg " + bin2hex ( qmsg["msg"].mid )+

" not sent after retries" )

self.retry_queue.remove(qmsg)

continue

self.debug ( "Retrying to send msg: " +

bin2hex(qmsg["msg"].mid) + "; " +

str(qmsg["retries"]-1) + " retries left" )

sent = self.send_msg ( qmsg["msg"], qmsg["src_addr"],

qmsg["dest_addr"] )

13

if sent and not qmsg["msg"].iflags & Message.REQ_ACK:

# don't wait for ack, remove msg from queue

self.retry_queue.remove(qmsg)

continue

qmsg["initial_time"] = time.time()

qmsg["retries"] -= 1

if qmsg["retries"] > 0:

qmsg["timeout"] *=self.retry_config["multiplier"]

else:

qmsg["timeout"] = Node.TIMEOUT

Svaka poruka se u red pohranjuje s podatkom o vremenskom trenutku kada je dodana u red. To vrijeme se dobiva pomoću standardne Python funkcije time. Glavna petlja funkcije prolazi kroz sve poruke u redu te provjerava da li je od trenutka kada je poruka dodana u red prošlo dovoljno vremena (timeout) da bi se pokušala retransmisija. Nakon toga provjerava se da li je poruka već poslana maksimalan dopušten broj puta (retries),

a ukoliko je, ispisuje se poruka o grešci te se ta poruka briše iz reda. Ako je proteklo dovoljno vremena i poruka se moţe poslati još barem jednom, ispisuje se poruka o

pokušaju retransmisije, te se pokušava poslati pomoću send_msg funkcije.

Ukoliko je poruka uspješno poslana, i poruka je takva da ne zahtijeva odgovor od čvora

primatelja, retransmisija je uspjela te se poruka briše iz reda.

Ako je poruka takva da zahtijeva odgovor, onda još ne postoji sigurnost da je sve dobro

prošlo, pa se poruka i dalje ostavlja u redu. Ona će iz njega biti maknuta intervencijom

kada čvor kasnije bude obraĎivao nove pristigle poruke i kada ustvrdi da je jedna od tih poruka odgovor na poruku poslanu retransmisijom.

Bez obzira da li je poruka uspješno ili neuspješno poslana, ako je nakon pokušaja slanja

i dalje u redu za retransmisiju, njeno vrijeme slanja se aţurira pribliţno na vrijeme

zadnjeg slanja. Nadalje, poruci se umanjuje preostali broj pokušaja retransmisije. Ako je

tada broj preostalih pokušaja veći od 0, vrijeme prije ponovnog slanja će se povećati za

faktor definiran u parametru multiplier. Ukoliko je broj pokušaja istrošen, poruka se ne

smije odmah obrisati uz poruku o grešci jer je moguće da je odredišni čvor primio

poruku i da je odgovor na putu. Stoga se poruci ostavlja još jedan dodatni period koji je

jednak periodu TIMEOUT koji je globalno definiran za cijeli čvor.

14

5. PRIMJERI ISPITNIH SLUČAJEVA

U ovom poglavlju dani su opisi nekolicine ispitnih slučajeva koji su napisani i testirani

tijekom izrade rada.

5.1. Primjer retransmisije

Konfiguracija sustava korištenog za ispitivanje retransmisiju jednaka je onoj opisanoj u poglavlju 3.3. U sustavu su sudjelovala dva čvora, nazvana user-1 i thing-1. Čvor user-1 posjeduje red za retransmisiju, što se moţe vidjeti iz definicije polja “retry“ u isječku

koda 5.1.

Datoteka .json kojom je inicijaliziran čvor user-1 dana je u nastavku. Odgovarajuća

.json datoteka za čvor thing-1 je veoma slična, ali ne sadrţi definiciju reda za

retransmisiju i ima drugačija pravila ponašanja u sekciji „rules“.

Isječak koda 5.1. Kompletna definicija čvora user-1

{

"node": [

{

"id": "0x1111111111111111",

"name": "user-1",

"key": "0x11111111111111111111111111111111",

"flags":[]

},

{

"id": "0x2222222222222222",

"name": "thing-1",

"key": "0x11111111111111112222222222222222",

"flags":[]

}

],

"address": [

{

"id": "0x1111111111111111",

"prio": 5,

"type": "IPv6",

"addr": {

"ip": "::1",

"port": 10000

},

"bcast": false,

"flags": ""

},

{

"id": "0x1111111111111111",

"prio": 1,

"type": "IPv4",

"addr": {

"ip": "127.0.0.1",

"port": 10001

},

"bcast": false,

"flags": ""

},

15

{

"id": "0x2222222222222222",

"prio": 5,

"type": "IPv6",

"addr": {

"ip": "::1",

"port": 50000

},

"bcast": false,

"flags": ""

}

],

"relay": [],

"data": [],

"config": {

"accept_encryption" : [ "HMAC", "DATA", "PACKET" ],

"process_received": [ "FOR_NODE" ],

"inner_flags" : [ "HMAC_SET", "ENCRYPTED", "REQ_ACK" ],

"outer_flags" : [ "HMAC_SET", "SRC_SET", "ENCRYPTED" ],

"request_ack": [ "FIRST_TIME" ],

"save_msg":[ "ALL" ],

"log_msg": [ "ALL" ],

"retry": { "timeout": 5, "retries": 3, "multiplier": 2 }

},

"rules":

[

{

"trigger": "not hasattr(NODE, 't1') or NOW-NODE.t1 >= 100",

"actions": [

"NODE.t1 = NOW",

"dest = hex2bin('2222222222222222')",

"data = bytes ('10:'+str(int(NOW)), 'utf-8' )",

"msg = NewMsg(NODE, src=ID, dest=dest, data=data)",

"NODE.send_message ( msg, dest )"

]

}

]

}

U definiciji čvora vidljivi su svi parametri i podatci spominjani u prethodnim

poglavljima. To su redom:

„node“ – opći podatci o svim poznatim čvorovima (identifikator, ime, javni ili

privatni ključ, i zastavice); prvi zapis na ovom popisu je opis samog čvora subjekta

16

„address“ – popis svih adresa, tj. veza svih čvorova za koje čvor subjekt zna;

veze koje imaju isti identifikator kao i sam čvor subjekt su njegove osobne

adrese

„relay“ – polje koje definira preko kojih čvorova se treba usmjeriti komunikacija namijenjena nekom odreĎenom čvoru ako se ne moţe direktno adresirati

„data“ – polje koje sluţi za pohranu zapisa o dogaĎajima tijekom rada čvora

„config“ – polje koje definira zastavice koje opisuju ponašanje čvora i vrste

poruka koje prihvaća i šalje; takoĎer sadrţi definiciju reda za retransmisiju

„rules“ – niz Python naredbi koje imaju svoj okidač; ako je okidač zadovoljen,

izvršavaju se ostale naredbe (izvršavanje naredaba i testiranje okidača se u

simulatoru vrši pomoću funkcije eval)

U „rules“ sekciji ovog čvora definirano je ponašanje kojim čvor pri pokretanju i svakih

100 sekundi nakon toga stvara novu poruku koju šalje čvoru thing-1 (identifikator: 2222222222222222). Čvor thing-1 u svojoj „rules“ sekciji definira ponašanje koje se

okida po primitku poruke, te kojim se stvara poruka odgovor i šalje prvotnom

pošiljatelju, čvoru user-1. Čvorovi biljeţe razmjenu poruka odgovarajućim ispisima na

terminal, kao na slici 5.1.

Slika 5-1 Normalna razmjena poruka

17

Kako bi se isprobala funkcionalnost reda za retransmisiju, namjerno je ugašen čvor

thing-1. Nakon toga, čvor user-1 i dalje na isti način pokušava komunicirati s čvorom

thing-1, ali mu to ne polazi za rukom. Stoga neuspješno poslane poruke sprema u svoj red za retransmisiju. Kada se nakon toga ponovno upali čvor thing-1, poruka se iz reda za retransmiju uspješno pošalje čvoru thing-1, te se uz odgovarajuću poruku briše iz

reda. Redovna komunikacija se u meĎuvremenu neometano nastavlja (ispisi ove situacije prikazani su na slici 5-2).

Slika 5-2 Ispis tijekom retransmisije

18

5.2. Primjer prosljeĎivanja

Konfiguracija sustava u ovom ispitnom slučaju je nešto sloţenija, sadrţi tri čvora: user-1, thing-1 i cloud-1. Zamisao je bila isprobati mehanizam prosljeĎivanja, tj. slučaj kada

čvor thing-1 treba poslati poruku čvoru user-1, ali ga ne moţe direktno adresirati.

MeĎutim, thing-1 (i user-1, zbog potrebe za odgovorom) u polju „relay“ (isječak koda

5-2) svoje .json datoteke ima definiran naputak da poruke namijenje za user-1 treba slati preko čvora cloud-1, koji moţe direktno adresirati oba preostala čvora. Parametar „prio“

označava prioritet veze, no to u ovom slučaju nije značajno jer se efektivno koristi samo jedna veza, tj. ne postoji alternativan put za poruku. Mehanizam prosljeĎivanja je uspješno iskorišten, a tijek komunikacije se moţe vidjeti na slici 5-3.

Isječak koda 5.2. Definicija prosljeĎivanja

"relay": [

{

"dest": "0x2222222222222222",

"relay": "0x3333333333333333",

"prio": 5

}

],

Slika 5-3 Komunikacija kod prosljeĎivanja

19

5.3. Primjer kolektora

Još jedan interesantan primjer je slanje poruke nespecificiranom čvoru za skupljanje podataka, tzv. kolektoru. Namjera ovog ispitnog slučaja bila je ispitati mogućnosti

simulatora za ovakvu situaciju (pravila za slanje u isječku koda 5.3.).

Isječak koda 5.3. Pravila za slanje kolektoru

"rules":

[

{

"trigger": "not hasattr(NODE, 't1') or NOW-NODE.t1 >= 10",

"actions": [

"NODE.t1 = NOW",

"dest = Node.COLLECTOR",

"data = bytes ('10:'+str(int(NOW)), 'utf-8' )",

"msg = NewMsg(self, src=ID, dest=dest, data=data)",

"NODE.send_message ( msg, dest, False )"

]

}

]

20

6. ZAKLJUČAK

Cilj ovog rada bio je istraţiti mogućnosti i probleme kod projektiranja IoT sustava, i ostvariti nekoliko primjera IoT sustava uz dostupne ureĎaje i programsku podršku. TakoĎer, po potrebi je trebalo ugraditi dodatne funkcionalnosti u korišteni simulator.

Ostvareno je više konfiguracija sustava, a neki zanimljiviji su i detaljnije ilustrirani kroz ispitne slučajeve. TakoĎer, u simulator je ugraĎena funkcionalnost retransmisije.

Iako postoji još mnogo zanimljivih primjena koje bi se mogle ispitati i razraditi, neposredan budući rad bi vjerojatno bio usmjeren na ispitivanje mogućnosti

komunikacije pomoću Wi-Fi tehnologije, te daljnja usavršavanja simulatora, npr. po

pitanju općeg odašiljanja.

21

LITERATURA

1. Internet of Things, https://en.wikipedia.org/wiki/Internet_of_things, 1. 6. 2016. 2. IoT Examples, http://postscapes.com/internet-of-things-examples/, 2. 6. 2016. 3. Iot simulator, https://github.com/l30nard0/dasiot, 5. 6. 2016.

22

SAŢETAK

Simulirati sustav Internet stvari korištenjem Raspberry Pi računala i EasyRadio

beţičnih modula

Ovaj rad daje pregled osnovnih problema kod projektiranja IoT sustava. Predloţena su

rješenja za neke od tih problema, te su dani primjeri sustava ostvarenih pomoću

Raspberry Pi računala i easyRadio modula.

Ključne riječi: IoT, arhitektura, Raspberry Pi, easyRadio

SUMMARY

Title: Simulate Internet of Things system using Raspberry Pi and EasyRadio wireless modules

Summary

The subject of this paper is an overview of the problems that arise in IoT systems design. Solutions for several of the problems are suggested, and backed up with actual test cases and configurations using Raspberry Pi and easyRadio.

Keywords: IoT, architecture, Raspberry Pi, easyRadio