razvoj sustava za nadzor i upravljanje korištenjem ... · ženje yocto za razvoj prilagodene slike...
TRANSCRIPT
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.
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
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