V nit serijski monitor smo vgradili tudi mehanizem zaznavanja neodzivno-sti eksperimentalne naprave, ki se zgodi v primeru napake v njeni kodi. Naprava mora vsaj enkrat v minuti nekaj izpisati na serijski vmesnik, sicer jo infrastruk-turna naprava oznaˇci za neodzivno s stanjem ˇcasovne omejitve (stanjeTIMEOUT).
Podoben mehanizem se izvaja tudi med ˇcakanjem na ukazni odziv: ˇce eksperimen-talna naprava na prejeti ukaz ne odgovori v roku treh sekund, jo infrastrukturna naprava podobno oznaˇci za neodzivno.
Poleg opisane primarne funkcionalnosti, lahko infrastrukturna naprava s pomoˇcjo programske niti serijski monitor tudi ponovno zaˇzene eksperimen-talno napravo VESNA. S podporo zbirke prevajalnih orodij (ang. GNU com-piler collection, GCC) lahko izvede postopek gradnje izvrˇsilne kode iz izvorne kode eksperimentalne aplikacije (predprocesiranje, prevajanje in povezovanje) in z orodjem OpenOCD21 naloˇzi prevedeno izvrˇsilno kodo na mikrokrmilnik.
4.3.4.4 Operacijski sistem Contiki-NG
Za izvajanje ˇstevilnih eksperimentov s platformo VESNA se v testnem omreˇzju uporablja operacijski sistem Contiki-NG. To je majhen, dogodkovni operacijski
21http://openocd.org/
4.3 Sistem za spremljanje in nadzor eksperimentov 57
sistem namenjen mikrokrmilnikom z omejenimi viri [41]. Kooperativni (ang. non-preemptive) model zagotavlja veˇcopravilnost s pomoˇcjo procesov, ki se proˇzijo ob doloˇcenih dogodkih in se morajo po konˇcanem delu zakljuˇciti in samodejno pre-dati procesorske vire razvrˇsˇcevalniku (ang. scheduler) [42]. Operacijski sistem poleg veˇcopravilnosti podpira tudi povezljivost v Internet z vgrajenim komunika-cijskim skladom IPv6. Uporabnik lahko konfigurira omreˇzje in doloˇci uporabljeno tehnologijo na posameznem nivoju sklada v konfiguracijski datoteki Makefile.
Program za eksperiment je obiˇcajno napisan kot svoj proces (na sliki 4.17 po-imenovan kot eksperimentalni proces), v katerem uporabnik definira njegov potek in se izvaja soˇcasno z ostalimi procesi v operacijskem sistemu. Najpogo-steje se uporabnik posluˇzi tehnike periodiˇcnega opravljanja meritev, ki jih izpisuje na serijski vmesnik. Infrastrukturno vozliˇsˇce bo meritve shranilo in kasneje po-sredovalo uporabniku. Primer preproste aplikacije za merjenje ˇsuma v ozadju (ang. background noise) prikazuje izsek kode spodaj. Proces vsako milisekundo pridobi meritev indeksa prejete moˇci signala (ang. received signal strength indi-cator, RSSI) in jo izpiˇse na serijsko povezavo.
PROCESS_THREAD(bgn_measurement_process, ev, data)
// Nastavi ˇcasovnik na eno sekundo etimer_set(&timer, SECOND/1000);
while(1) {
// Pridobi RSSI meritev RF2xx radia in jo izpiˇsi rf2xx_driver.get_value(RADIO_PARAM_RSSI, &rssi);
printf("Measured RSSI: %d \n", rssi);
// Poˇcakaj na iztek ˇcasovnika in ga nato ponastavi PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&timer));
etimer_reset(&timer);
}
// Konec procesa PROCESS_END():
}
Za podporo sistema za spremljanje in nadzor nad eksperimenti smo nare-dili knjiˇznico napisano v programskem jeziku C, ki jo uporabnik vkljuˇci v svojo aplikacijo eksperimenta. Proces serial input process (na sliki 4.17 poimeno-van kot serijski proces), ki zaˇcne z izvajanjem takoj po zagonu operacijskega sistema, deluje kot vmesnik za prejemanje ukazov. Ob inicializaciji gre v bloki-rano stanje, kjer ne porablja procesorske moˇci in ˇcaka na proˇzenje z dogodkom serial line event message. Ob proˇzenju proces prebere medpomnilnik preje-tih znakov na povezavi UART in ga primerja z nizom razpoloˇzljivih ukazov. ˇCe je prejet ukaz prepoznan, proces pridobi ˇzeleno informacijo in jo vrne na infra-strukturno napravo s poslanim nizom preko serijske povezave in za tem preda kontrolo razvrˇsˇcevalniku.
// Ob prejetju ukaza "START", zaˇzeni proces process_start(&experiment_process, NULL);
}
else if(strcmp(cmd, cmd_stop) == 0){
// Ob prejetju ukaza "STOP", ustavi proces process_exit(&experiment_process);
} // ...
}
4.3 Sistem za spremljanje in nadzor eksperimentov 59
Knjiˇznica ponuja tudi vkljuˇcitev namenskih procesov za izvajanje aplikacij.
Med njimi je osnovni experiment process, ki ga lahko uporabnik zaˇzene z upo-rabo nadzornega sistema in poslanim ukazom START. Isti proces se ustavi, ko uporabnik poˇslje ukaz STOP, kot je razvidno tudi iz izvleˇcka kode zgoraj. S tem je uporabniku omogoˇcena izvedba eksperimentalne aplikacije z moˇznostjo roˇcnega zagona, ki je uporabna predvsem v primeru, ko uporabnik ˇzeli poˇcakati formacijo eksperimentalnega omreˇzja pred priˇcetkom opravljanja ˇzelene meritve. Knjiˇznica ponuja tudi predpripravljen periodiˇcen proces, ki se samodejno priˇcne ob zaˇcetku delovanja operacijskega sistema. Namenjen je preverjanju doloˇcene spremenljivke in poˇsiljanju njenega stanja za prikaz do uporabnika. Primer takˇsnega je lahko periodiˇcen proces merjenja ˇsuma v ozadju prikazan zgoraj.
Uporabnik lahko v knjiˇznico preprosto doda nove ukaze in spreminja pred pripravljene procese, ki morajo biti ˇcim krajˇsi, da ne posegajo v delovanje ope-racijskega sistema (Contiki-NG je dogodkovni operacijski sistem in za razliko od realno ˇcasovnih ne prekinja procesov, ampak ˇcaka na konec njihove izvedbe).
4.4 Vkljuˇ citev v sistem IMBA
Program krmilnik bi arhitekturno lahko postavili tako, da kot vzporedna nit deluje soˇcasno sstreˇzniˇsko aplikacijo. Vendar smo se zaradi naslednjih razlogov odloˇcili za drugaˇcno izvedbo:
• Vsak eksperiment naj ima svoj krmilnik - svojega nadzornika z bazo podatkov o tekoˇcem eksperimentu. V primeru, da se bo uporabnost te-stnega omreˇzja razˇsirila na soˇcasno izvajanje eksperimentov z veˇc napravami hkrati, bo lahko vsak eksperiment dobil svojkrmilnik.
• Spletna stran mora biti uporabniku dostopna ves ˇcas, tudi ˇce se eksperiment ne izvaja, kar pa ne velja za program krmilnik.
• Ze obstojeˇˇ ci sistem SMS platforme je namenjen tudi drugim testnim omreˇzjem, kjer se razˇsiritev opisana v tem delu ne uporablja. Obseˇznejˇsi posegi v SMS platformo poslediˇcno niso zaˇzeleni.
4.4.1 Vkljuˇcitev v sistem avtomatskega zagona eksperimentov
Za postavitev entitete krmilnik v sistem avtomatskega zagona eksperimentov, opisanega v poglavju 3.2, smo sestavili novo datoteko Docker. Vsebuje vse po-trebne odvisnosti (okolje Python in knjiˇznico ZeroMQ) in ob zagonu samodejno zaˇzene programkrmilnika (skripto controller.py). Vsebnik Docker izpostavi 3 IP vrata, vsakega za svoj komunikacijski kanal ZeroMQ: enega za streˇzniˇsko aplikacijo in dva za vozliˇsˇca, na katera se naprave kasneje poveˇzejo.
Za samodejno vzpostavitev vsebnika, smo v sistem avtomatskega za-gona eksperimentov dodali novo Ansible Playbook skripto imenovano release controller.yml. Ob zaˇcetku eksperimenta se iz vsebnika SMS preko povezave SSH poveˇze na streˇznik za upravljanje. Tu skripta prenese eksperi-mentalen repozitorij iz hrambe GitHub, kjer najde zgoraj opisano datoteko Doc-ker. Slednjo streˇznik zgradi v sliko in iz nje naredi vsebnik poimenovan krmil-nik. Slika 4.18 prikazuje arhitekturo novega sistema. Uredili smo tudi Ansible Playbook skripto collect results.yml, ki po konˇcanem eksperimentu poleg
4.4 Vkljuˇcitev v sistem IMBA 61
vrnitve rezultatov eksperimenta uporabniku ustavi vsebnik krmilnik in sprosti uporabljene vire na streˇzniku za upravljanje.
Slika 4.18: Avtomatski sistem zagona eksperimentov z razˇsiritvijo.
Infrastrukturne naprave izvajajo eksperiment v vsebniku Docker, kot smo opisali v poglavju 3.2.1. Za podporo sistema za nadzor eksperimentov pa morajo imeti nameˇsˇcenih nekaj novih odvisnosti. V ta namen smo za vozliˇsˇcne naprave naredili novo sliko Docker, ki temelji na operacijskem sistemu Ubuntu Linux22. Za hitrejˇsi zagon eksperimentov, smo ˇze zgrajeno sliko shranili v trgovini Dockerhub, od kjer jo lahko naprave prenesejo in preprosto zaˇzenejo.
4.4.2 Vkljuˇcitev v SMS portal
Spletni portal SMS je zapakiran v isto imenski vsebnik Docker, v katerem posre-dovalni streˇznik (ang. proxy server) Nginx23 skrbi za prenos uporabniˇskih zahtev.
Vsa orodja (opisana v 3.1) so ob zagonu vsebnika samodejno pognana s progra-mom Supervisord24 in za komunikacijo z internetnim omreˇzjem izpostavijo vrata IP (ang. IP port). Uporabnikova zahteva je preko streˇznika Nginx posredovana do iskanega orodja, kar omogoˇca uporabniku dostop do vseh podprtih orodij na istem spletnem naslovu, kot nakazuje slika 4.19.
22https://ubuntu.com/
23https://nginx.org/en/
24http://supervisord.org/
Slika 4.19: Posredovanje zahtev uporabnika v vsebniku Sensor Managament Sy-stem.
Streˇzniˇska aplikacija je vkljuˇcena v vsebnik SMS na podoben naˇcin kot ostala orodija za upravljanje s tesnim omreˇzjem. Za samodejni zagon smo jo dodali v program Supervisord tako, da se streˇznik Flask samodejno postavi in izpostavi vrata s ˇstevilko 5563. S konfiguracijo Nginx proksija smo nato dosegli, da je vsaka zahteva na spletnem portalu, namenjena sistemu za nadzor eksperi-mentov, posredovana do izpostavljenih vrat.
Za posredovanje paketov med proksijem Nginx in streˇznikom Flask smo med njima dodali streˇznik Gunicorn WSGI25, ki hkrati zagotavlja veˇcjo varnost in s pomoˇcjo knjiˇznice Python Eventlet26 omogoˇca soˇcasen dostop do spletne strani veˇc klientom hkrati.
25https://gunicorn.org/
26https://eventlet.net/
5 Prikaz delovanja
V tem poglavju je na dveh praktiˇcnih primerih predstavljeno in ovrednoteno delovanje v tem delu opisane razˇsiritve - sistema za spremljanje in nadzor eks-perimentov v testnem omreˇzju LOG-a-TEC. Prvi primer opisuje eksperiment z infrastrukturno napravo SNA-LGTC, drugi pa z eksperimentalno napravo - plat-formo VESNA.
5.1 Eksperiment Bluetooth z infrastrukturno napravo SNA-LGTC
Bluetooth Low Energy (BLE) je komunikacijski protokol s ciljem nizke porabe elektriˇcne energije. Uporablja 2.4 GHz frekvenˇcni pas in omogoˇca uporabo veˇcih komunikacijskih topologij (zankasta (ang. mesh), od naprave do naprave (ang.
point-to-point) in komunikacija z veˇc prejemniki (ang. multicast))[43]. Poleg ˇsiroke komunikacijske uporabnosti se v zadnjem ˇcasu izrablja tudi tudi za na-tanˇcno doloˇcanje lokacije naprav in merjenje razdalj med njimi.
V testnem omreˇzju LOG-a-TEC smo z desetimi infrastrukturnimi napravami, ki so opremljene z radijskim vmesnikom WL1837MOD, pripravili eksperiment za doloˇcanje lokacije naprav. Med delovanjem vsako vozliˇsˇce periodiˇcno oddaja svoj oglaˇsevalni paket (ang. advertising beacon), hkrati pa zaznava in shranjuje pakete preostalih BLE oddajnikov. Ob prejemu sporoˇcila naprava shrani njegov izvorni naslov in indikator sprejete moˇci signala (ang. received signal strength in-dicator, RSSI), ki ga uporabimo za doloˇcanje lokacije naprave, ki je paket poslala.
Vozliˇsˇca uporabljena v eksperimentu prikazuje slika 5.1, primer konˇcnega rezul-63
tata pa slika 5.2. Graf rezultatov je narejen z algoritmom najmanjˇsih kvadratov.
Predstavlja primer doloˇcanja pozicije ene izmed naprav s pomoˇcjo meritev ostalih sedmih.
Slika 5.1: Primer uporabniˇskega vmesnika med potekom eksperimenta lokalizacije s tehnologijo Bluetooth.
Izvedbo eksperimenta smo si olajˇsali z novim sistemom za spremljanje in nadzor eksperimentov. Po sproˇzitvi avtomatskega zagona eksperimenta smo na grafiˇcnem vmesniku opazovali pridruˇzevanje izbranih vozliˇsˇc. Do sedaj bi naprave samodejno zaˇcele izvajati eksperimentalne aplikacije, tudi v primeru zaostajanja ostalih naprav pri pridruˇzevanju, ki je lahko na primer posledica daljˇsega pripra-vljanja testnega okolja (vsebnika Docker). Z novim sistemom pa lahko zaˇcetek eksperimenta uskladimo in z ukazomSTARTsoˇcasno poˇzenemo aplikacijo na vseh vozliˇsˇcih hkrati. Uspeˇsen prejem ukaza START so naprave oznanile s prehodom v stanje RUNNING (vidna na sliki 5.1). Vozliˇsˇca so med izvajanjem testne apli-kacije vsako odkritje nepoznane naprave najavila v izhodno konzolo, kar nam je omogoˇcalo analizo poteka eksperimenta v realnem ˇcasu. Kot je razvidno tudi na sliki 5.1, se v izhodno konzolo izpiˇse ime naprave, ki je poslala sporoˇcilo in naslov MAC odkritega radia.
5.2 Testiranje omreˇzja 6TiSCH z eksperimentalno napravo VESNA 65
Eksperiment lahko brez ponovne sproˇzitve avtomatskega sistema za zagon eksperimentov kadarkoli ustavimo ali ponovno zaˇzenemo, kar moˇcno zmanjˇsa ˇcas izvajanja, saj slednji za izvedbo potrebuje tudi po veˇc minut (v povpreˇcju 8). Ko naprave zakljuˇcijo z izvajanjem, se postavijo v stanjeFINNISHED(ikone vozliˇsˇc se pobarvajo v sinje modro) in eksperiment lahko nato zakljuˇcimo z ukazomEXIT.
Slika 5.2: Primer doloˇcitve lokacije ene izmed naprav s pomoˇcjo meritev ostalih.
5.2 Testiranje omreˇ zja 6TiSCH z eksperimentalno na-pravo VESNA
Standard IEEE 802.15.4e je namenjen brezˇziˇcni komunikaciji v nestabilnih omreˇzjih z nizko porabo (ang. low power and lossy networks, LLNs). V dru-gem nivoju njegovega modela OSI, poznan kot nadzor dostopa do medijev (ang.
medium access control, MAC), je med drugimi definiran naˇcin komunikacije s pre-skakovanjem kanala s ˇcasovno reˇzo (ang. time slotted channel hopping, TSCH), ki temelji na veˇckratnem dostopu s ˇcasovno razdelitvijo (ang. time division multiple access, TDMA) [44]. Pristop omogoˇca, da naprave uporabljajo iste frekvenˇcne kanale z delitvijo komunikacije v ˇcasovne rezine, kar izboljˇsa zanesljivost izme-njevanja sporoˇcil v ˇsumnem okolju in zniˇzuje porabo energije [45]. Protokol
6Ti-SCH, katerega poimenovanje je izpeljano iz angleˇskega izraza IPv6 over TSCH (slo. IPv6 preko TSCH), omogoˇca napravam v njegovem omreˇzju ˇse povezljivost v Internet [46].
Komunikacija v omreˇzju 6TiSCH je koordinirana s pomoˇcjo urnika, ki je moˇcno odvisen od potreb aplikacije. V njem je ˇcas razdeljen v ˇcasovne rezine, tipiˇcne dolˇzine 10 ms, veˇc rezin skupaj pa predstavlja okvirje terminov (ang. slot frame), ki se s ˇcasom ponavljajo [46]. Kot je razvidno iz slike 5.3, so sestavljeni iz celic, kjer vsaka izmed njih doloˇca ˇcasovno rezino in frekvenˇcni kanal, na katerem bo potekala komunikacija med dvema vozliˇsˇcema.
Slika 5.3: Primer urnika protokola 6TiSCH.
Standard IEEE 802.15.4e nudi v frekvenˇcnem pasu 2,4 GHz uporabo 16 ka-nalov [44]. V urniku so definirani pred zaˇcetkom delovanja in so vedno isti. ˇCe je ob poˇsiljanju doloˇcen kanal zaseden in je poslediˇcno prenos paketa neuspeˇsen, se poˇsiljanje ponovi na drugem frekvenˇcnem kanalu (do 8-krat). Predlaganih je bilo kar nekaj nadgradenj protokola 6TiSCH [47], s katerimi lahko naprave di-namiˇcno prilagajajo urnik in izloˇcijo zasedene kanale ter s tem izboljˇsajo zaneslji-vost komunikacije. Eno izmed njih smo testirali v testnem omreˇzju LOG-a-TEC.
Implementirana je v operacijski sistem Contiki-NG in se imenuje RSSI upstream driven adaptive channel selection strategy (slo. prilagodljiva izbira kanala na podlagi meritev RSSI) [47]. Naprave preverjajo zasedenost kanala s cikliˇcnim merjenjem RSSI vrednosti. ˇCe izmerjena vrednost v trenutni sekvenci pade pod prednastavljen prag, potem ga naprave izloˇcijo iz urnika in najdejo zamenjavo.
Za namene analiziranja nadgradnje protokola 6TiSCH smo v testnem omreˇzju
5.2 Testiranje omreˇzja 6TiSCH z eksperimentalno napravo VESNA 67
LOG-a-TEC naredili eksperiment z eksperimentalnimi napravami VESNA, opre-mljenimi z radijskimi vmesniki AT86RF231. Za merjenje kvalitete komunikacije vozliˇsˇca najprej vzpostavijo testno omreˇzje, nato koordinator omreˇzja periodiˇcno izbira nakljuˇcno vozliˇsˇce, mu poˇslje paket in priˇcakuje odgovor nanj. S ˇstetjem ˇstevila poslanih in prejetih paketov lahko doloˇcimo razmerje napake (ang. packet error rate, PER). Za simulacijo ˇsumnega okolja smo s tremi vozliˇsˇci proizvajali ˇsum na razliˇcnih frekvencah in poslediˇcno testirali zmoˇznost izogibanja zasede-nega kanala.
Opravili smo 3 eksperimente: a) eksperiment za doloˇcanje delovanja 6TiSCH protokola brez ˇsumenja, b) eksperiment za doloˇcanje delovanja protokola 6Ti-SCH v ˇsumnem okolju, c) eksperiment v ˇsumnem okolju z nadgradnjo protokola 6TiSCH. Rezultati so podani v tabeli 5.1. Z njimi lahko potrdimo, da je pro-tokol 6TiSCH zmoˇzen izvajati komunikacije tudi v ˇsumnem okolju. Poleg tega opazimo, da se ob uporabi protokola brez nadgradnje ˇstevilo ponovno poslanih paketov moˇcno poviˇsa, kar poslediˇcno poviˇsa porabo energije naprav in zakasnitve v omreˇzju.
Tabela 5.1: Rezultati eksperimentov s protokolom 6TiSCH.
Opisane eksperimente smo izvedli s pomoˇcjo sistema za spremljanje in nad-zor eksperimentov, ki smo ga dopolnili z ukazi in stanji vozliˇsˇc nakazanimi med opisom dela. Z njim smo prilagajali in opazovali topologijo eksperimentalnega omreˇzja. Kot primer, z ukazom ROOT smo izbrali koordinatorja omreˇzja, kar v monitorju stanj nakazuje ikona s ˇcrno obrobo in stanje napraveROOT NETWORK. Z novim orodjem smo lahko opazovali proces pridruˇzevanja naprav k omreˇzju ko-ordinatorja v realnem ˇcasu (ikone vozliˇsˇc dobijo belo obrobo). ˇSele ko so bile vse
naprave del eksperimentalnega omreˇzja, smo aplikacijo pognali. S tem smo za-gotovili, da so vsa vozliˇsˇca del 6TiSCH omreˇzja pred dejansko izvedbo aplikacije, ˇ
cesar prejˇsnji sistem ni omogoˇcal.
Slika 5.4: Realno ˇcasovna stanja vozliˇsˇc med potekom eksperimenta: a) Uspeˇsen zagon eksperimenta in proces grajenja, b) proces pridruˇzevanja omreˇzju 6TiSCH, c) izvajanje eksperimentalne aplikacije, ˇc) stanje zakljuˇcene eksperimentalne apli-kacije.
Postopen prikaz stanj in prehodi med njimi prikazuje slika 5.4. Po zagonu ek-sperimenta so vse infrastrukturne naprave najprej gradile izvrˇsilno kodo za plat-formo VESNA (slika 5.4a) in se po naloˇzitvi kode postavile v stanjeONLINE (siva barva ikon na sliki 5.4b). Z ukazomROOTsmo vozliˇsˇce na sredini testnega omreˇzja izbrali za koordinatorja omreˇzja in poˇcakali, da so se ji ostala vozliˇsˇca pridruˇzila ter nato zagnali eksperimentalno aplikacijo z ukazom START. Uspeˇsen zagon so vozliˇsˇca nakazala s prehodom v stanjeRUNNING(zelene ikone na sliki 5.4c), konec eksperimenta pa s stanjemFINISHED(sinje modre ikone na sliki 5.4ˇc). ˇCrne ikone na sliki 5.4 prikazujejo pozicije naprav za proizvajanje ˇsuma.
5.2 Testiranje omreˇzja 6TiSCH z eksperimentalno napravo VESNA 69
Slika 5.5: Primer izhodne konzole upravitelja eksperimentov med potekom eks-perimenta 6TiSCH.
Med potekom eksperimenta smo v izhodni konzoli upravitelja eksperimen-tov v realnem ˇcasu opazovali dogajanje na koordinatorju omreˇzja, kot prikazuje slika 5.5. Vozliˇsˇce je vanj izpisovalo seznam uporabljenih kanalov in njihovo kako-vost. Tako smo lahko potrdili delovanje ˇsumnih generatorjev, hkrati pa opazovali, kako si naprava izbira zamenjavo za zaseden kanal in s tem analizirali delovanje nadgrajenega protokola. Brez tovrstnega orodja bi morali informacije poiskati v tekstovni datoteki, ki jo prejmemo po koncu eksperimenta, kar lahko predstavlja zamudno opravilo. Ob nepravilnem delovanju aplikacije bi tako tudi za manj ˇ
cakali na konec eksperimenta, namesto da bi ˇze prej ukrepali in ponovno zagnali aplikacijo. Poleg tega prejˇsnji sistem ni ponujal moˇznosti enostavne zaustavitve eksperimenta, kar pa nov sistem omogoˇca s preprostim vnosom ukaza. Vozliˇsˇce je izpisovalo tudi vsak prejet odziv in naslov poˇsiljatelja, s ˇcimer smo potrdili pravilno delovanje eksperimentalne aplikacije. Periodiˇcno je izpisovalo tudi iz-merjeno statistiko njegovega radia, tako da smo v realnem ˇcasu opazovali, koliko sporoˇcil je radio poslal in koliko jih je prejel.
6 Sklepne ugotovitve in zakljuˇ cek
V magistrski nalogi smo opisali testno omreˇzje LOG-a-TEC in predstavili razˇsiritev njegove funkcionalnosti s sistemom za spremljanje in nadzor ekspe-rimentov. Na podlagi zahtev smo zastavljen problem razˇclenili na veˇc elementov, katere smo realizirali in opisali v poglavju 4 in na koncu dodali opis implementa-cije v ˇze obstojeˇc sistem IMBA.
Pri razvoju smo skuˇsali izpolniti vse zadane zahteve in cilje, podane v pod-poglavju 4.1. Zaradi zastavljenega sistema izmenjevanja sporoˇcil, nitenja in veˇcopravilnosti se pri uporabi orodja (pri poˇsiljanju in prejemanju ukazov ter pri opazovanju spreminjanja stanj) le obˇcasno pojavijo krajˇse zakasnitve. Opa-zne so predvsem pri eksperimentih s platformo VESNA, kar je dopustno, saj je delovanje infrastrukturne naprave nastavljeno tako, da ima eksperiment prednost pred uporabnikom. Z uvedbo mehanizmov za zaznavanje neodzivnosti eksperi-mentalne naprave smo poskrbeli za zanesljivost delovanja. V sistem izmenjevanja sporoˇcil bi lahko kot nadgradnjo vnesli ˇse postopek zaznavanja delovanja infra-strukturnih naprav. Sedaj v primeru napake v programu uporabnik to opazi ˇsele, ko vozliˇsˇcu poˇslje sporoˇcilo in nanj ne prejme odgovora. Tak mehanizem nadzora nad vozliˇsˇci bi lahko izvedli z metodo srˇcnega utripa (ang. heart beat), s katero bi krmilnik vozliˇsˇcem periodiˇcno poˇsiljal zahteve in priˇcakoval odzive nanje. V primeru neodzivnosti to nakazuje na napako na vozliˇsˇcu, o ˇcemer lahko opozori uporabnika.
S pomoˇcjo dveh eksperimentov, predstavljenih v poglavju 5, smo na dejanskih primerih prikazali uporabnost razvitega sistema. Izkazalo se je za zelo praktiˇcno in uporabno orodje, ki razvijalcem predstavlja veliko pomoˇc pri analiziranju po-teka eksperimentov. Moˇznost upravljanja aplikacije med potekom omogoˇca
iz-71
vedbo kompleksnih eksperimentov, prikaz stanja vozliˇsˇca pa nudi hitro in jasno povratno informacijo. ˇCeprav je trenutni grafiˇcni vmesnik dovolj za prikaz osnov-nih stanj, se tu ponuja veliko moˇznosti za nadgradnjo. Na primer pri eksperi-mentu z omreˇzjem 6TiSCH bi bil grafiˇcni prikaz povezave med dvema vozliˇsˇcema zelo uporaben. Z njim bi imel uporabnik na voljo informacije o trenutni sestavi in dogajanju, v tem izredno dinamiˇcnem eksperimentalnem omreˇzju. Vendar bi bila implementacija tovrstne funkcionalnost v trenutni realizaciji grafiˇcnega vme-snika, izdelanega z HTML elementi, zelo zahtevna. Vsekakor bi bila tu potrebna dodatna analiza ustreznosti ostalih primernih orodij in okolij.
vedbo kompleksnih eksperimentov, prikaz stanja vozliˇsˇca pa nudi hitro in jasno povratno informacijo. ˇCeprav je trenutni grafiˇcni vmesnik dovolj za prikaz osnov-nih stanj, se tu ponuja veliko moˇznosti za nadgradnjo. Na primer pri eksperi-mentu z omreˇzjem 6TiSCH bi bil grafiˇcni prikaz povezave med dvema vozliˇsˇcema zelo uporaben. Z njim bi imel uporabnik na voljo informacije o trenutni sestavi in dogajanju, v tem izredno dinamiˇcnem eksperimentalnem omreˇzju. Vendar bi bila implementacija tovrstne funkcionalnost v trenutni realizaciji grafiˇcnega vme-snika, izdelanega z HTML elementi, zelo zahtevna. Vsekakor bi bila tu potrebna dodatna analiza ustreznosti ostalih primernih orodij in okolij.