SVEUCILIŠTE U ZAGREBUFAKULTET ELEKTROTEHNIKE I RACUNARSTVA

ZAVRŠNI RAD br. 4781

Razvoj sustava za nadzor iupravljanje korištenjem okruženja

YoctoJosip Kvakaric

Zagreb, lipanj 2017.

iii

SADRŽAJ

1. Uvod 1

2. Sustavi za nadzor i upravljanje 22.1. Podjela prema modelu . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2. Kontrolna ploca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Yocto projekt 43.1. Poky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2. BitBake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3. Slika operacijskog sustava . . . . . . . . . . . . . . . . . . . . . . . 6

4. Dizajn sustava 84.1. Baza podataka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2. OneWire protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. Klijentska aplikacija 135.1. Registracija i korisnicki kljuc . . . . . . . . . . . . . . . . . . . . . . 13

5.2. Upravljanje uredajima i mjerenjima . . . . . . . . . . . . . . . . . . 14

6. Aplikacija u razvojnom okviru Qt 166.1. Priprema uredaja za rad . . . . . . . . . . . . . . . . . . . . . . . . . 19

7. Zakljucak 20

Literatura 21

A. Postavke za izgradnju slike 22

B. Znacajni dijelovi izvornog kôda 24

iv

1. Uvod

Sustavi za nadzor i upravljanje su sustavi cija je primarna zadaca obrada ulaznih po-

dataka dobivenih iz razlicitih izvora i stvaranje prikladnog odziva ovisno o sadržaju

prikupljenih podataka. Izvori sadržaja mogu biti razliciti senzori za prikupljanje iz

okoline, poruke koje stvara sam sustav, rucni ljudski unos i drugi.

Iako sustavi za nadzor i upravljanje mogu varirati velicinom i složenošcu, njihova

se zadaca u gotovo svim slucajevima svodi na nekoliko osnovnih radnji od kojih su

najbitnije prikupljanje podataka, njihovo maksimalno sažimanje i neobavezno obav-

ljanje odredene akcije ovisno o ulaznoj vrijednosti. Prikupljanjem podataka bitno je

obuhvatiti sve podatke koji mogu biti od koristi u razumijevanju konacnog sadržaja.

Sažimanje prikupljenih podataka je postupak kojim se unaprijed definiranim skupom

pravila i metoda za obradu podatci filtriraju i združuju u skupove. Sustav na obra-

dene podatke može odgovoriti samostalno ili uz dodatan ljudski unos te aktivno obav-

ljajuci odredenu proceduru predvidenu za stanje u kojem se sustav našao ili pasivno

prosljedujuci obavijest o zaprimljenim podatcima, obicno prema sucelju koje je jasno

razumljivo i najcešce sadrži graficki prikaz[1].

Razvoj mreža senzora vec je našao široku primjenu u razlicitim granama industrije

gdje iste mogu pridonijeti poboljšanju kvalitete konacnog proizvoda i smanjenju tro-

škova izrade na temelju analiza ili sudjelovati u prikupljanju informacija znacajnih za

velik broj ljudi poput automatizirane prevencije požara ili pracenja zdravlja i korelacije

s mjerenim parametrima poput cistoce zraka na odredenom podrucju.

Vec iz navedenog vidljiv je potencijal i mogucnosti primjene ovakvih sustava. Iz

tog je razloga tijekom rada opisan razvoj primjerka jednog ovakvog sustava te su opi-

sani ucestali problemi koji se pritom javljaju i koristi koje je moguce ostvariti.

Tijekom razvoja sustava za nadzor i upravljanje u ovom radu upotrijebljeno je okru-

ženje Yocto za razvoj prilagodene slike operacijskog sustava namijenjene uredajima

koji ce vršiti mjerenja, razvojni okvir Qt za razvoj programske podrške koja ce po-

goniti obradu na strani uredaja i razvojni okvir ASP.NET Core za razvoj klijentske

aplikacije s prikazom podataka i upravljanjem uredajima.

1

2. Sustavi za nadzor i upravljanje

Sposobnosti sustava na nadzor i upravljanje u opcenitom su slucaju detekcija, preven-

cija i stvaranje odgovora na širok spektar dogadaja. Nadzor se odnosi na promatranje,

bilježenje i izvještavanje o stanju sustava, njegovih komponenata i o dogadajima koji se

u njemu odvijaju. Pracenjem ovih vrijednosti moguce je utvrditi ispravnost podataka s

uredaja u sustavu. Nadzor može biti izveden na dva nacina. Komponente sustava mo-

guce je pratiti kontinuirano, tj. u stvarnom vremenu s frekvencijom i odzivom takvima

da je stanje vidljivo vanjskom svijetu u vremenu reda velicine sekunde što omogucuje

pravovremenu reakciju tijekom faze upravljanja. Sustav je moguce pratiti i u serijama

tijekom odredenih tocaka u vremenu. Upravljanje se s druge strane odnosi na dijelove

sustava cijim je ponašanjem moguce upravljati rucno ili automatski u odnosu na stanje.

Pritom razlikujemo akcije zabrane i ispravljanja.

Za razumijevanje ovih sustava bitan je termin „kontrolna petlja“1. To je cjelina

sastavljena od dijela za upravljanje, ciljnog sustava, dvosmjerne komunikacije i skupa

podataka u razmijeni. Zatvoreni tip petlje je onaj u kojem nije neophodna interak-

cija covjeka i gdje su procesi u sustavu automatizirani dok otvoreni tip ukljucuje in-

terakciju s covjekom. Tip petlje odreduju tehnicki zahtjevi sustava koji su odredeni

vrstom radnji i nacinom na koji ih sustav mora moci ispunjavati. Posljedicno, defi-

nirani sustav moguce je koristiti i za obavljanje mnogih drugih zadataka za koje nije

inicijalno bio namijenjen, a neki od kojih mogu predstavljati neželjene mogucnosti sus-

tava — npr. konzumiranje sadržaja zabavnog karaktera ili P2P komunikacija s drugim

uredajima[1]. Ovi problemi mogu biti riješeni dizajnom mreže i reguliranjem kontrole

pristupa pojedinog ili grupa korisnika.

2.1. Podjela prema modelu

Prema modelu sustava vršimo podjelu na cetiri opce kategorije. Sustavi s unutraš-

njom kontrolom (engl. internal) su najjednostavniji, oni prate sami sebe i to najcešce1U vecini je sustava, cak i onih automatiziranih, covjek dio kontrolne petlje.

2

kroz razna ogranicenja prava i bilježenje stanja sustava (engl. logging). Sljedeca ka-

tegorija su sustavi s modelom „jedan na jedan“ gdje jedan sustav može istovremeno

pratiti najviše jedan udaljeni samostalni sustav. Ovi sustavi teže skaliraju, ali su pri-

mjereni za okruženja gdje je potrebna visoka dostupnost i jednostavan oporavak od

pogrešaka.2 Najcešce upotrebljavani model je „jedan na više“ gdje jedan sustav može

pratiti u teoriji neogranicen broj drugih cime se smanjuju troškovi i složenost puštanja

u produkciju[1]. Postoji još i distribuirani model kod kojeg uredaji obavljaju radnje sa-

mostalno ili na temelju uputa od središnjeg upravljackog sustava te podatke pohranjuju

u zajednicki spremnik.

2.2. Kontrolna ploca

Kontrolne ploce jedan su od najbitnijih dijelova sustava za nadzor i upravljanje jer pru-

žaju uvid u sve relevantne pracene podatke sažete tako da budu lako razumljivi kraj-

njem korisniku, uobicajeno kroz isjecke cistog teksta i razne vizualne elemente poput

dijagrama, tablica i slika. Sucelja kontrolnih ploca najcešce su izvedena web tehnolo-

gijama zbog lakšeg pristupa s veceg broja klijentskih racunala putem web preglednika.

Pozadinske tehnologije (engl. backend) ukljucuju bazu podataka s podatcima potreb-

nim za prikaz kljucnih informacija o stanju sustava u gotovo stvarnom vremenu kada

je to potrebno i razvojni okvir pomocu kojeg je te podatke moguce obraditi i poslati

sucelju kontrolne ploce. Detaljnijim informacijama cesto je moguce pristupiti rucno

korištenjem upravljacke konzole sustava koja je zbog funkcionalnih zahtjeva sustava

gotovo uvijek potrebna.3

2U ovakvom je scenariju moguc oporavak samo odredenih dijelova sustava prilikom greške uz pret-

postavku da su sustavi nezavisni i da greška u jednom nije izazvala lancanu reakciju.3Iako je kontrolna ploca jedan od bitnijih dijelova sustava, zbog postojanja upravljacke konzole

njezino je postojanje neobavezno.

3

3. Yocto projekt

Yocto je projekt otvorenog kôda ciji je cilj olakšati razvoj i prilagodbu operacijskog

sustava za ciljno sklopovlje pomocu sustava za sklapanje vlastitih i unaprijed defini-

ranih komponenata. Takvu funkcionalnost Yocto omogucava korištenjem Poky sustava

za izgradnju temeljenog na OpenEmbedded projektu i BitBake alatu cija je osnovna

namjena upravljanje distribucijama i paketima potrebnim tijekom izgradnje kompo-

nenata za ugradena racunala s operacijskim sustavom temeljenim na Linux jezgri za

ARM, MIPS, PowerPC i x86 arhitekture. Za potrebe ovog rada kao pokazni primjer

odabran je uredaj Raspberry Pi 3 i sukladno tome razvijen operacijski sustav i pro-

gramska podrška za arhitekturu ARM.

3.1. Poky

Termin Poky ima više znacenja. Najcešce predstavlja projekt otvorenog kôda koji je

razvila tvrtka OpenedHand, a kasnije preuzela tvrtka Intel nakon cega je Poky postao

osnova projekta Yocto. Imenu „poky“ odgovara ime repozitorija izvornog kôda pa ga

se može promatrati i kao lokalnu inacicu sadržanih podataka. Poky je i referentna dis-

tribucija projekta Yocto koja sadrži OpenEmbedded sustav za izgradnju i alat BitBake

zajedno s polaznim skupom metapodataka i pripadajucom dokumentacijom. On služi

kao „ljepilo“ komponenata koje dolaze u njegovu sastavu. Poky je zamišljen kao opip-

ljiva pocetna cjelina s provjerenom kvalitetom i repozitorij pouzdanih alata i izvornog

kôda sa šestomjesecnim ciklusom izdavanja novih verzija.

Povijesno je Poky postojao paralelno s OpenEmbedded-om i bio njegova ogoljena

inacica namijenjena za specificne ciljne okoline. Nastankom Yocto projekta i razdva-

janjem OpenEmbedded-a na više manjih cjelina Poky postaje referentni sustav za iz-

gradnju jer su riješeni neki od problema zbog kojih je Poky postojao zasebno[2].

Tijekom ovog rada termin Poky ce predstavljati lokalnu kopiju repozitorija izvor-

nog kôda i drugih sadržanih alata i podataka.

4

3.2. BitBake

U osnovi, BitBake je izvršitelj zadataka koncepcijski vrlo slican alatu GNU Make uz

sljedece bitne razlike. Alat BitBake izvršava zadatke ciji se redoslijed utvrduje dina-

mickim stvaranjem stabla ovisnosti pomocu metapodataka iz parsiranih .bb, .conf

i .bbclass datoteka. Ovaj pristup omogucuje automatsko ukljucivanje odredenih

skupina paketa i relativno jednostavno stvaranje konacne slike primjerene za instala-

ciju na stvarnom uredaju. Osim toga, u sklopu alata dostupna je knjižnica za dohvat

izvornog kôda iz razlicitih izvora i podrška za udaljeno upravljanje pomocu XML-RPC

(engl. Remote Procedure Call) protokola[2].

Slika 3.1: Proces nastanka slike operacijskog sustava

Recept (.bb) je datoteka s osnovnim opisom metapodataka jednog ili cjeline pro-

grama. On BitBake-u pruža podatke poput autora, dozvole i inacice recepta, skupa

ovisnosti, lokacije repozitorija izvornog kôda, potrebnih postavki te nacina prevodenja

dohvacenog izvornog kôda i putanje za instalaciju dobivenog programa. Datoteke s

postavkama (.conf) sadrže popis raznih varijabli preko cijih je vrijednosti moguce

upravljati procesom izgradnje projekta. U ovoj su datoteci najcešce zapisane definicije

ciljnog sklopovlja i parametara željene distribucije. Klase (.bbclass) su datoteke s

pohranjenim podatcima koji su korisni ostatku sustava i trebaju biti dijeljeni izmedu

5

datoteka s metapodatcima. Datoteka base.bbclass sadrži osnovne opise i upute

za izvršavanje zadataka tijekom procesa izgradnje koje druge datoteke s metapodat-

cima mogu nadjacavati i proširivati. Slojevi (engl. layers) su logicke cjeline cija je

svrha što veca modularizacija projekta s ciljem ostvarivanja mogucnosti što vece po-

novne upotrebe manjih cjelina za podešavanje, a datoteke dodataka (engl. append file)

(.bbappend) su neobavezne i dolaze u paru s odgovarajucim receptom te pružaju

mogucnosti izmijene ili nadopune podataka iz recepata.

Slika 3.2: Struktura projektnih datoteka

Struktura projektnih datoteka vidljiva je na slici 3.2. Prethodno spomenute .bb,

.conf, .bbclass i .bbappend pripadaju slojevima projekta Yocto. Slojevi su

podijeljeni na osnovne slojeve koji su dio referentne distribucije projekta te dodatne

korisnicki definirane slojeve. Direktorij scripts opremljen je izmedu ostalog i da-

totekom oe-setup-builddir cija je uloga stvoriti pocetnu strukturu direktorija

za izgradnju (engl. build) koju vidimo u gornjem desnom kutu slike. Definicije dru-

gih slojeva sacinjenih od istih tipova datoteka mogu se nalaziti bilo gdje u datotecnom

sustavu i referenciraju se navodenjem njihove apsolutne ili relativne putanje u odnosu

na direktorij za izgradnju.

3.3. Slika operacijskog sustava

Prije stvaranja slike operacijskog sustava potrebno je racunalo domacina opremiti od-

govarajucim skupom alata potrebnih BitBake-u tijekom procesa izgradnje slike. Na-

kon dobavljanja alata i željene inacice sustava za izgradnju potrebno je pomocu skripte

oe-init-build-env podesiti radnu okolinu i postaviti odgovarajuce varijable okru-

6

ženja. Uobicajena je praksa sve specificne izmjene postavaka unositi iskljucivo u da-

toteke direktorija za izgradnju zbog ocuvanja pocetnih slojeva koje je u tom slucaju

moguce paralelno koristiti za izgradnju više razlicitih slika.

Podešavanje dijela parametara slike postiže se uredivanjem datoteka local.conf

i bblayers.conf u direktoriju za izgradnju. Unosom novih slojeva u datoteku

bblayers.conf dobivamo na raspolaganje skup unaprijed definiranih recepata i

slika koje je u svrhu ostvarenja dizajna sustava opisanog u 4. poglavlju potrebno proši-

riti. To je ostvareno definiranjem novog recepta za izgradnju slike

qt5-full-image.bb[7]. Konkretan sadržaj navedene datoteke i ostale postavke

korištene tijekom izgradnje citatelj može pronaci u Dodatku A.

Po završetku definicije slike, stvaranje iste moguce je pokrenuti naredbom bitbake

uz neobavezno zadavanje zastavice -n zbog koje ce alat samo proci kroz sve zadatke

i utvrditi njihovu ispravnost, ali nece izgraditi konacnu sliku sustava ili zastavice -k

koja u slucaju greške omogucuje nastavak izgradnje svih preostalih paketa koji prema

grafu ovisnosti ne ovise o paketu kod kojeg je došlo do pogreške.

Konacnu sliku nakon toga je moguce uobicajenim metodama instalirati na medij s

trajnom pohranom i mogucnošcu pokretanja operacijskog sustava.

7

4. Dizajn sustava

Cilj ovog rada je razvoj primjera sustava za nadzor i upravljanje koji može ostvariti ko-

munikaciju s vecim brojem uredaja i na temelju ulaznih podataka definiranih u sustavu

izvršiti odredeni oblik obrade na uredajima ukljucenima u sustav te stvoriti izvještaje

o stanju uredaja i prikljucenih senzora kroz vrijeme.

Kako bi sustav raspolagao trajno pohranjenim i što korisnijim podatcima potrebno

je definirati bazu podataka s pripadnim tablicama. Odabrana je baza podataka Post-

greSQL jer je u potpunosti otvorenog kôda, mnogo bolje prati i implementira funkci-

onalnosti propisane SQL standardom i nudi cijeli niz složenijih tipova i mogucnosti

u odnosu na druge popularne baze podataka otvorenog kôda te vrlo dobru podršku za

odabrane razvojne okvire Qt i ASP.NET Core. Nadalje, upis redaka u tablice je u ovom

sustavu cesta operacija zbog potrebe za raspolaganjem što „svježijim“ podatcima pa

prikljuceni uredaji bazu podataka moraju osvježavati u malim serijama ili pojedinac-

nim upisima, što je zbog interne arhitekture PostgreSQL-a brža i jeftinija operacija

nego kod primjerice MySQL baze. Citanje tablica s manjim brojem redaka vjerojatno

ce biti sporije, ali i znatno rjede izvodena operacija.1 Dodatno, zapisi iz tablice mjere-

nja s uredaja ce gotovo uvijek biti dohvacani u velikim serijama. Uzmemo li u obzir

scenarij s vecim brojem korisnika, svi citani podatci ne mogu stati izravno u memoriju,

a u tom je slucaju PostgreSQL opet prikladniji zbog nacina grupiranja podataka. Iako

bi u pocetnom dizajnu sustava neki jednostavniji sustav za upravljanje bazom podataka

bilo jednostavnije implementirati, uz sve dosad nabrojane prednosti, potencijalne bu-

duce nadogradnje ili redizajn dijelova sustava ovako ce biti nešto lakše provesti ukoliko

se ukaže ta potreba.

Odabir tehnologija za izradu klijenta jednako je bitan kada razmotrimo scenarij s

velikim brojem korisnika, ali nije žarište ovog rada pa nece biti detaljnije analiziran.

Odabran je razvojni okvir ASP.NET Core na .NET Core-u. Odabir web tehnologije

u ovom je slucaju logican izbor zbog lakše dostupnosti korisnicima, bržeg razvoja i

1Ovdje se pretpostavlja da ce tablica koja sadržava mjerenja s uredaja imati višestruko veci broj

redaka od ostalih te da ce eksponencijalno brže rasti dugotrajnim korištenjem sustava.

8

uklanjanja potrebe za instalacijom na svako klijentsko racunalo.

Najbitniji dio sustava, aplikacija za citanje i obradu podataka na uredajima, bit ce

izradena u razvojnom okviru Qt koji je prethodno ukljucen u sliku Yoctom razvije-

nog operacijskog sustava.2 Osim razvojnog okvira Qt, za izradu ovakvih aplikacija

najcešce se koriste jezici C i C++ bez razvojnih okvira zbog cesto ogranicenih sistem-

skih resursa. Podrška za rjede korištene alternative poput Pythona, C# ili Jave dio su

Yocto projekta i moguce ih je ukljuciti u konacnu sliku korištenjem slojeva kao što su

meta-python, meta-mono te meta-java ili meta-oracle-java.

Slika 4.1: Struktura dijelova razvijenog rješenja

Na slici 4.1 moguce je vidjeti kako izgledaju medusobno integrirani dijelovi sus-

tava. Komunikacija komponenata je dvosmjerna, ali staje kod uredaja kojima se uprav-

lja. Uredaje je prije pocetka korištenja potrebno prikladno prilagoditi za spajanje na

mrežu i dodijeliti im željeno ime i identifikacijski kljuc korisnika vlasnika aplikacije.3

Žarište sustava je jedinstvena udaljena baza podataka putem koje uredaji razmjenjuju

poruke s klijentskom aplikacijom. Ovaj nacin komunikacije upotrebljen je jer u ovom

slucaju ne stvara dodatnu složenost u dizajnu sustava zbog potrebe postojanja baze

podataka za središnju pohranu mjerenja, a rješava problem adresiranja4 velikog broja2Postavke za dobivanje spomenute slike dostupne su u Dodatku A.3Ovaj je proces detaljnije opisan u odjeljcima 5.1 i 6.1.4Protokol IPv6 još uvijek nije dovoljno prihvaceno rješenje u trenutku pisanja ovog rada.

9

uredaja koji ne trebaju biti prisutni u istoj lokalnoj mreži vec samo spojeni na mrežu s

omogucenim pristupom bazi podataka. Prilikom stvaranja uredaja, svakom je dodije-

ljen jedinstveni identifikator i ime uredaja (engl. hostname) pomocu kojih je uredaj iz

sucelja klijentske aplikacije uparen sa svojim stvarnim duplikatom ako je isti ispravno

podešen. Dodatno, zbog vec spomenutog podešavanja uredaja unosom korisnickog

kljuca moguce je osigurati prava pristupa korisnika samo odredenom podskupu defini-

ranih uredaja, a zbog postojanja identifikatora svakog uredaja i korisnika, moguce je u

buducnosti jednostavnim dodatkom tablice prava pristupa dozvoliti korisniku vlasniku

upravljanje razinama prava pristupa njegovim uredajima za druge korisnike.

Predvideni tok informacija kroz sustav je sljedeci. Krajnji korisnik u sucelju kli-

jentske aplikacije registrira vlastiti profil i željeni broj uredaja koje pritom oprema

potrebnim postavkama i unaprijed pripremljenom izvršnom datotekom aplikacije iz 6.

poglavlja. Korisnik potom definira aktivna mjerenja koja želi vršiti na uredaju i za koja

je uredaj pripremio. Pravilno postavljeni uredaj koji periodicki proziva bazu podataka

dolazi do skupa postavki dostupnih pod njegovim imenom, kljucem i kljucem koris-

nika vlasnika te pocinje s periodickim izvještavanjem o traženim dijelovima svojeg

stanja.

4.1. Baza podataka

U prethodno opisanom sustavu postoji potreba za definiranjem struktura koje ce pred-

stavljati korisnika, uredaj, vrstu uredaja, vrstu mjerenja, trajno pohranjeno mjerenje s

uredaja i aktivno mjerenje koje se trenutno provodi. Model baze podataka sa spome-

nutim tablicama nalazi se na slici 4.2.

Relativno velik broj stranih kljuceva prisutnih u ovom modelu potreban je da bi

se trajno uspostavila veza izmedu korisnika i svih poruka o stanju ciji je on izravni

vlasnik. Veze uredaja, mjerenja i aktivnog mjerenja potrebne su zbog prikaza izvora

podataka. Primjerice, kada se obriše zapis iz tablice aktivnog citanja, tada i dalje pos-

toji potreba prikaza pripadnosti nekog mjerenja odredenom uredaju što bi bez ovih

veza bilo nemoguce. Tablice ReadingType i DeviceType namijenjene su raspoznavanju

vrsta uredaja i mjerenja na temelju kojih ce se odlucivati o nacinu obrade zadanog ak-

tivnog mjerenja i prikladnom prikazu podataka putem tablica ili grafikona u klijentskoj

aplikaciji.

10

Slika 4.2: Model baze podataka bez tablica za provjeru autenticnosti

4.2. OneWire protokol

Za potrebe ovog rada u opisanom sustavu implementirana je obrada ocitanih vrijed-

nosti sa senzora temperature DS18B20-PAR koji koristi OneWire protokol te je stoga

isti ovdje opisan. OneWire je jednostavni protokol tvrtke Dallas Semiconductor za se-

rijski prijenos podataka koji koristi samo dvije žice od kojih je jedna podatkovna, a

druga spojena na uzemljenje. Ovaj protokol karakteriziraju prijenosni paketi male ve-

licine i male brzine prijenosa, jeftina implementacija i relativno velike razdaljine preko

kojih je moguce ostvariti prijenos podataka.5 OneWire protokol najcešce se koristi u

malim i jeftinim uredajima poput temperaturnih senzora ili iButton uredaja.

Svaki OneWire uredaj ima jedinstveni i nepromjenjivi 64-bitni identifikator dodi-

jeljen prilikom proizvodnje koji služi za adresiranje podredenih (engl. slave) senzora

spojenih na OneWire sabirnicu upravljanu glavnim (engl. master) uredajem. Isprav-

5Podatke je moguce prenijeti na udaljenost od nekoliko stotina metara.

11

nost podataka provjerava se zaštitnom CRC sumom. Korištenje iste žice za napajanje

i prijenos podataka omoguceno je postojanjem ugradenog kondenzatora koji tijekom

ciklusa kada je aktivna podatkovna veza služi za napajanje uredaja[4].

OneWire uredaji mogu biti napajani na prethodno opisani parazitski nacin koji zah-

tijeva samo dvije žice i pull-up otpornik od 4.7 kΩ izmedu podatkovne linije i napa-

janja, a mogu se napajati i klasicnim putem kada je treci prikljucak uredaja prikljucen

izravno na napajanje, a otpornik od 4.7 kΩ spojen izmedu napajanja i podatkovne li-

nije. Primjer ovakvog spajanja uredaja možemo vidjeti na slici 4.3.

Slika 4.3: Primjer spajanja OneWire uredaja

12

5. Klijentska aplikacija

Razvijenim dijelovima sustava pripada i klijentska aplikacija koja predstavlja kon-

trolnu plocu — sucelje visoke razine koje krajnjem korisniku treba olakšati ceste za-

datke u upravljanju uredajima i pružiti sažet uvid u stanje podešenog sustava i skupine

prikupljenih mjerenja po uredajima i izvorima aktivnih mjerenja. Rješenje ovog dijela

sustava razvijeno je kao web aplikacija kako bi omogucilo što vecem broju korisnika

što lakši pristup.

Buduci da sustavu može pristupati veci broj korisnika rješenje je opremljeno pro-

vjerom autenticnosti implementiranom pomocu ASP.NET Identity sustava. Ovaj pris-

tup osigurava korisnicima privatnost njihovih resursa na mreži i omogucava proširenja

implementacije ulogama, znackama, dvostrukom provjerom autenticnosti ili provje-

rom autenticnosti putem OAuth protokola preko pružatelja takvih usluga.

5.1. Registracija i korisnicki kljuc

Prilikom registracije korisnik popunjava obrazac s korisnickim imenom, adresom elek-

tronicke pošte i lozinkom. Nakon što prijava prode validaciju i korisnik potvrdi svoj

racun1, odobren mu je pristup dijelu sucelja gdje može pristupiti upravljanju uredajima

i aktivnim mjerenjima.

Nakon inicijalnog dodavanja željenih postavki, bitan je dio dohvata korisnickog

identifikatora kojem se može pristupiti pritiskom na adresu elektronicke pošte i otvara-

njem prozora pod View Account Id. Prikaz pristupa pregledu korisnickog identifikatora

vidljiv je na slici 5.1. Ovaj je kljuc bitan zbog kasnijeg povezivanja s postavljenim ure-

dajima.

1Potvrda korisnickog racuna obavlja se odlaskom na adresu poslanu korisniku elektronickom po-

štom.

13

Slika 5.1: Pregled identifikatora korisnika

5.2. Upravljanje uredajima i mjerenjima

Upravljanje uredajima nalazi se pod karticom Devices gdje je moguce dodavanje, pro-

mjena, brisanje te pregledavanje dodatnih informacija i mjerenja za pojedini uredaj.

Aktivacija mjerenja obavlja se pritiskom na poveznicu Manage gdje je slicne radnje

moguce obaviti i za model aktivnog mjerenja ispunjavanjem obrazaca s imenom, vr-

stom i putanjom do datoteke s ocitanjem na uredaju. Prilikom stvaranja novog mjerenja

bitno je zapamtiti ime dodijeljeno uredaju (engl. hostname) koje u kombinaciji s iden-

tifikatorom korisnika služi za prepoznavanje pripadnih postavki tijekom rada programa

na uredajima.

U sucelju pregleda mjerenja moguce je vidjeti tablicni prikaz proteklih mjerenja

koja su pocetno kronološki poredana. Kako do spremanja zapisa mjerenja ili stanja na

uredaju dolazi relativno cesto, snalaženje u velikom broju mjerenih podataka moguce

je sortiranjem i mješovitim pretraživanjem po svim stupcima zapisa. Prikaz pregleda

mjerenja na uredajima vidljiv je na slici 5.2.

14

Slika 5.2: Pregled mjerenja sa svih uredaja

15

6. Aplikacija u razvojnom okviru Qt

Svaki uredaj potrebno je opremiti odgovarajucom programskom podrškom koja ce na

uredaju u ovisnosti o definiranim postavkama u bazi podataka kontinuirano vršiti mje-

renja. Ova je programska podrška izradena u razvojnom okviru Qt i treba aktivno

pratiti dodavanje novih komponenata u klijentskoj aplikaciji i zapisa u bazi podataka.

Prije pocetka razvoja same aplikacije, potrebno je iz postavki korištenih za izradu

slike operacijskog sustava stvoriti primjereni skup razvojnih alata (engl. Software De-

velopment Kit) koji odgovara arhitekturi središnje procesorske jedinice ciljnog sustava.

Za izvršavanje ove radnje koristi se vec spomenuti alat BitBake i unaprijed pripremljeni

recept meta-toolchain-qt5 iz sloja meta-qt5.

Dobiveni skup razvojnih alata sadrži prevoditelj i sve ostale module i knjižnice do-

dane postavkama za izgradnju slike. Njegovom instalacijom stvara se dodatna struk-

tura u datotecnom sustavu racunala domacina slicna onoj kakvu nalazimo na ureda-

jima opremljenima izgradenom slikom operacijskog sustava. Ovaj korak omogucava

razvoj programske podrške za uredaje s razlicitom arhitekturom iz okruženja racunala

domacina[8].

Prilikom izrade Qt aplikacija uobicajeno se koristi integrirano razvojno okruženje

Qt Creator koje je takoder potrebno prikladno podesiti za korištenje dobivenog skupa

alata. Potrebno je prije svakog pokretanja razvojnih alata pokrenuti naredbu source

nad skriptom environment-setup-cilj-poky-linux koja se nalazi u pod-

sustavu stvorenom instalacijom razvojnih alata. Ova skripta privremeno podešava

okruženje za korištenje novostvorenih alata te nadjacava neke varijable okruženja i

zadane postavke na racunalu domacinu. Razvojne alate potrebno je pokrenuti iz lju-

ske u kojoj su obavljene prethodne naredbe kako bi razvojna okolina djelovala u istom

okruženju.

Povezivanje s uredajem za razvoj izvodi se dodavanjem odgovarajuceg skupa alata

u postavkama Qt Creator-a i njegovim povezivanjem s prikladnim prevoditeljima, ala-

tom za pracenje izvršavanja programa (engl. debugger) i knjižnicama razvojnog okvira

Qt koje odgovaraju arhitekturi ciljnog sklopovlja, a nalazimo ih u medu novoinstali-

16

ranim alatima. Zatim je pod karticom Devices potrebno dodati Linux uredaj te ga

povezati s njegovom trenutnom IP adresom. Za komunikaciju s uredajem koristi se

protokol SSH pa je port potrebno postaviti na 22 ako isti nije prethodno promijenjen

na uredaju.

Nakon stvaranja novog projekta potrebno je još samo dodati zadatak (engl. task)

koji ce prilikom svake izgradnje napisanog izvornog kôda izvršiti prijenos izvršnih da-

toteka na povezani uredaj i iste pokrenuti ako je izgradnja bila uspješna. To je moguce

ostvariti dodavanjem isjecka kôda 6.1 u .pro datoteku projekta.

Kôd 6.1: Dodatak postavkama projekta

QT += core sql

QT -= gui

CONFIG += c++11

CONFIG += console

TARGET = ime-aplikacije

target.files = ime-aplikacije

target.path = /home/ime-korisnika

INSTALLS += target

Medu prvim linijama prethodnog isjecka vidimo i dio postavaka za dodavanje po-

drške za SQL, uklanjanje modula za graficko korisnicko sucelje te dodavanje opcije

console kojom dajemo instrukciju prevoditelju da ce projekt biti konzolna (engl. head-

less) aplikacija[5].

Razvijenu aplikaciju cini nekoliko razreda od kojih je središnji AppLoop. Ovaj se

razred brine za stvaranje pocetnog stanja aplikacije, provjeru postojanja osnovnih pos-

tavaka za podešeni uredaj u bazi podataka i postavljanje kronometara za periodicku

sinkronizaciju s bazom podataka. Dodatno, ovaj razred posjeduje referencu na vektor

aktivnih mjerenja koji periodicki osvježava dodavanjem novih ili brisanjem uklonje-

nih aktivnih mjerenja postavljenih u klijentskoj aplikaciji. Prilikom stvaranja svakog

novog aktivnog mjerenja podešava se njegov vlastiti kronometar koji po isteku svakog

ciklusa poziva metodu update() razreda ActiveReading koja stvara novi primjerak mje-

renja1 na aktivnom uredaju i obavlja ocitanje primjereno vrsti uredaja i mjerenja. Kôd

najbitnijih dijelova razreda ActiveReading i AppLoop moguce je vidjeti u Dodatku B.

Stvaranje novih mjerenja ispravnog tipa ostvareno je korištenjem oblikovnog obrasca

1Mjerenje je reprezentirano apstraktnim razredom Reading cija svojstva odgovaraju atributima ta-

blice Readings u bazi podataka. Ovaj razred posjeduje i cistu virtualnu metodu measure(QString data-

Filepath) koju moraju implementirati svi konkretni razredi izvedeni iz Reading nudeci pritom algoritam

prikladan za obradu odredene vrste mjerenja.

17

metode tvornice (engl. factory method) koja omogucava razdvajanje klijentskog dijela

kôda od implementacija konkretnih mjerenja[3]. Metoda Reading::make_reading(int

readingTypeId) vraca pokazivac na tipski ispravnu vrstu mjerenja kojoj kasnije pristu-

pamo kroz referencu nadrazreda pa ce zbog polimorfizma i prema Liskovinom nacelu

supstitucije metoda measure() odraditi ispravan posao bez znanja o postojanju kon-

kretnih implementacija razreda Reading. Sažeti prikaz implementacije stvaranja tipski

ispravnih mjerenja dostupan je u isjecku kôda 6.2.

Kôd 6.2: Stvaranje primjerka razreda Reading

Reading* Reading::make_reading(int readingTypeId)

if(readingTypeId == RTID::TemperatureOneWire)

return new ReadingTemperatureOneWire;

// svi ostali konkretni podrazredi razreda Reading

else return nullptr;

Iz prethodnog je opisa vidljivo da je aplikaciju vrlo lako proširiti novim nacinima

obrade mjerenja. Sve što je u tom slucaju potrebno napraviti je naslijediti razred

Reading i ponuditi implementaciju njegove ciste virtualne metode measure(QString

dataFilepath) te registrirati postojanje novog razreda u enumeraciji RTID i u bazi

podataka[6].

Slika 6.1: Primjer spajanja senzora na uredaj

18

6.1. Priprema uredaja za rad

Prilikom pripreme uredaja za rad potrebno je vec spomenute vrijednosti korisnickog

identifikatora i imena uredaja koji su dohvaceni iz sucelja klijentske aplikacije upisati u

datoteku s postavkama appconfig i datoteku s imenom uredaja /etc/hostname.

Nadalje, potrebno je prikljuciti sve željene senzore na odgovarajuce pinove uredaja

i ostvariti podatkovnu vezu s prikljucenim senzorom. U meduvremenu je potrebno

u sucelju klijentske aplikacije dodati novo aktivno mjerenje uredaju istog imena ciji

parametri odgovaraju prikljucenom senzoru.

Nacin prikljucivanja jednostavnog temperaturnog senzora DS18B20-PAR temelje-

nog na OneWire protokolu s uredajem Raspberry Pi 3 možemo vidjeti na slici 6.1.

Osim datoteke appconfig potrebno je na svakom uredaju ispuniti i datoteku

dbconfig ispravnim podatcima za pristup bazi podataka. Ovi podatci nisu ukljuceni

u aplikaciju kao dio izvornog kôda da bi se olakšala potencijalna promjena postavaka

u hodu. Podatci za pristup bazi podataka koje je potrebno navesti su IP adresa racu-

nala na kojem se nalazi baza podataka, ime baze podataka, ime korisnika i lozinka za

pristup.

19

7. Zakljucak

Temeljem prikupljenog znanja o sustavima za nadzor i upravljanje razvijen je jedan

primjerak ovakvog sustava namijenjen pracenju stanja dodanih uredaja i mjerenju oci-

tanja na njih prikljucenih senzora. Korištenjem okruženja Yocto uspješno je izradena

slika operacijskog sustava za arhitekturu ARM koji je u ovom slucaju podloga ra-

zvijenoj programskoj podršci. Operacijskom sustavu su dodani moduli potrebni za

prevodenje i izvodenje konzolnih aplikacija razvijenih uz pomoc programskih paketa

razvojnog okvira Qt.

Zatim je u istom razvojnom okviru razvijena aplikacija za pracenje stanja uredaja

koja ovisno o postavkama dohvacenim iz središnjeg spremnika podataka obraduje po-

datke s uredaju prikljucenih senzora i periodicki osvježava bazu podataka. Napravljen

je pregled protokola OneWire i integracija temperaturnog senzora DS18B20-PAR u

sustav. Zbog jednostavnosti pristupa vrlo brzo rastucem broju podataka, razvijena je

i klijentska web aplikacija koja komunicira s istom bazom podataka i pruža moguc-

nosti upravljanja uredajima i mjerenjima te sažet prikaz svih relevantnih podataka s

detaljnim opcijama sortiranja i filtriranja.

Sva programska rješenja razvijena su da budu lako nadogradiva gdje je god to bilo

moguce zbog potencijalnih buducih proširenja sustava implementacijama drugih na-

cina obrade rezultata senzorskih mjerenja s kojima bi porasla i primjenjivost aplikacije

u nekom stvarnom okruženju.

20

LITERATURA

[1] Seymour Bosworth, Michel E. Kabay, i Eric Whyne. Computer Security Hand-

book. John Wiley & Sons, 2014.

[2] Linux Foundation. Yocto Project Mega-Manual. URL http://www.

yoctoproject.org/docs/2.2/mega-manual/mega-manual.

html. 25.5.2017.

[3] Erich Gamma, Richard Helm, Ralph Johnson, i John Vlissides. Design Patterns:

Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.

[4] Maxim Integrated. Overview of 1-Wire Technology and Its Use. URL https://

www.maximintegrated.com/en/app-notes/index.mvp/id/1796.

28.5.2017.

[5] G. Lazar i R. Penea. Mastering Qt 5. Packt Publishing Ltd, 2016.

[6] Julijan Šribar i Boris Motik. Demistificirani C++. Element, 2014.

[7] Jumpnow Technologies. Building Raspberry Pi Systems

with Yocto. URL http://www.jumpnowtek.com/rpi/

Raspberry-Pi-Systems-with-Yocto.html. 18.4.2017.

[8] P. J. Texier i P. Mabacker. Yocto for Raspberry Pi. Packt Publishing Ltd, 2016.

21

Dodatak APostavke za izgradnju slike

Kako bi citatelj dobio što precizniju sliku razvijenog sustava, ovdje je naveden sažeti

sadržaj recepta qt5-full-image.bb i dijelovi datoteka s postavkama kljucni za

ispravan rad izgradenog operacijskog sustava.

Kôd A.1: Recept korišten za izgradnju slike

# ...

require qt5-image.bb

QT5_EXTRAS = " \

bc ufw cmake libgcc boost sqlite3 \

qttools wiringpi \

"

IMAGE_INSTALL += " \

$QT5_EXTRAS \

"

export IMAGE_BASENAME = "qt5-full-image"

Kôd A.2: Definicija slojeva u datoteci bblayers.conf

# ...

BBLAYERS ?= "/home/korisnik/poky/meta \

/home/korisnik/poky/meta-poky \

/home/korisnik/poky/meta-openembedded/meta-oe \

/home/korisnik/poky/meta-openembedded/meta-multimedia \

/home/korisnik/poky/meta-openembedded/meta-networking \

/home/korisnik/poky/meta-openembedded/meta-python \

/home/korisnik/poky/meta-qt5 \

/home/korisnik/poky/meta-raspberrypi \

/home/korisnik/poky/meta-rpi \

"

22

Kôd A.3: Sadržaj datoteke local.conf

LICENSE_FLAGS_WHITELIST = "commercial"

PACKAGECONFIG_append_pn-qtbase = " sql-psql sql-sqlite freetype"

# ...

IMAGE_FSTYPES = "tar.xz"

PREFERRED_VERSION_linux-raspberrypi = "4.9.%"

MACHINE = "raspberrypi3"

DISTRO = "poky"

PACKAGE_CLASSES = "package_ipk"

DISABLE_OVERSCAN = "1"

DISPMANX_OFFLINE = "1"

ENABLE_UART = "1"

ENABLE_RPI3_SERIAL_CONSOLE = "1"

SDKMACHINE = "x86_64"

EXTRA_IMAGE_FEATURES = "debug-tweaks"

USER_CLASSES = "image-mklibs image-prelink"

PATCHRESOLVE = "noop"

23

Dodatak BZnacajni dijelovi izvornog kôda

U ovom su dodatku navedeni dijelovi izvornog kôda najbitniji za rad aplikacije na

ugradbenom racunalu. Radi ocuvanja jezgrovitosti i jednostavnosti, dugi ili manje

bitni dijelovi kôda su izostavljeni.

Kôd B.1: Dodavanje novog izmjerenog stanja

void ActiveReading::update()

Reading *reading = Reading::make_reading(

RTIDMap::map.value(readingTypeId_));

if(reading != nullptr)

reading->measure(dataFilepath_);

QSqlDatabase db = DbConnection::getInstance().db();

// ...

QSqlQuery query(db);

QString queryString = "INSERT INTO \"Readings\" ...";

if (query.exec(queryString);

// ...

// ...

24

Kôd B.2: Osnovna petlja aplikacije

void AppLoop::updateActiveReadings()

QSqlDatabase db = DbConnection::getInstance().db();

// ...

QSqlQuery query(db);

query.exec("SELECT * FROM \"Devices\" WHERE ...);

while (query.next())

QString qDeviceId = query.value(0).toString();

query.exec("SELECT * FROM \"ActiveReadings\" WHERE

\"DeviceId\" = ’" + qDeviceId + "’");

while (query.next())

// ...

activeReadings_.clear();

QString qActiveReadingDeviceId = query.value(3).toString();

if(qDeviceId == qActiveReadingDeviceId)

ActiveReading *activeReading = new ActiveReading(...);

activeReadings_.push_back(activeReading);

// ...

25

Razvoj sustava za nadzor i upravljanje korištenjem okruženja Yocto

Sažetak

Tijekom ovog rada razvijena je programska podrška u obliku sustava za nadzor i

upravljanje. Razvijena je slika operacijskog sustava za ARM arhitekturu korištenjem

okruženja Yocto. Konkretan primjerak radnog sustava ostvaren je pomocu uredaja Ras-

pberry Pi 3 i temperaturnog senzora temeljenog na OneWire protokolu. Razvijene

su dvije aplikacije, konzolna aplikacija u razvojnom okviru Qt namijenjena pracenju

stanja uredaja i web aplikacija u razvojnom okviru ASP.NET Core koja predstavlja

kontrolnu plocu sustava i krajnjem korisniku služi za interakciju sa sustavom te nudi

metode detaljnog pretraživanja prošlosti mjerenja. Ostvareno je periodicko osvježa-

vanje baze podataka zapisima o novim mjerenjima i provjera autenticnosti korisnika

aplikacije korištenjem sustava ASP.NET Identity.

Kljucne rijeci: Poky, BitBake, Qt, senzori, OneWire protokol, ASP.NET Core, Pos-

tgreSQL, ugradbena racunala, konzolna aplikacija, provjera autenticnosti, kontrolna

ploca

Monitoring and control applications development using Yocto project

Abstract

As a part of this paper, system monitoring and control software was developed.

Operating system image targeting ARM architecture was built using Yocto project.

Working sample of this system was achieved using Raspberry Pi 3 device and OneWire

based temperature sensor. Two applications were developed, headless Qt application

for monitoring the device state and ASP.NET Core web application representing a da-

shboard with detailed history and filtering options for end users. Headless application

was developed to perform periodic updates with new readings to the database. Finally,

user authentication was implemented using ASP.NET Identity system.

Keywords: Poky, BitBake, Qt, sensors, OneWire protocol, ASP.NET Core, Post-

greSQL, embedded systems, headless application, authentication, dashboard