• Rezultati Niso Bili Najdeni

SISTEM ZA SPREMLJANJE IN NADZOR EKSPERIMENTOV V

N/A
N/A
Protected

Academic year: 2022

Share "SISTEM ZA SPREMLJANJE IN NADZOR EKSPERIMENTOV V"

Copied!
97
0
0

Celotno besedilo

(1)

Univerza v Ljubljani

Fakulteta za elektrotehniko

GREGA MORANO

SISTEM ZA SPREMLJANJE IN NADZOR EKSPERIMENTOV V

BREZŽIČNEM TESTNEM OMREŽJU LOG-A-TEC

Magistrsko delo

Magistrski študijski program druge stopnje Elektrotehnika

Mentor: doc. dr. Janez Puhan

Somentor: izr. prof. dr. Tomaž Javornik

Ljubljana, 2021

(2)
(3)
(4)
(5)

Zahvala

Za vso strokovno pomoˇc, trud in vloˇzen ˇcas se iskreno zahvaljujem doc. dr.

Janezu Puhanu in izr. prof. dr. Tomaˇzu Javorniku. Hvala za potrpeˇzljivost in konstruktivne komentarje na moje delo.

Zahvaljujem se dr. Andreju Hrovatu za podporo in usmeritve med potekom raziskovanja. Hvala za vse nasvete in kritike, ki so me vzpodbudile pri izpopol- njevanju dela.

Zahvaljujem se dr. Matevˇzu Vuˇcniku, Ivanu Boˇskovu in vsem ostalim sode- lavcem na Oddelku za komunikacijske sisteme na Institutu “Joˇzef Stefan”, Lju- bljana, za vse ideje in nove poglede na reˇsitev teˇzav, ki so se pojavile pri realizaciji zakljuˇcnega dela.

Zahvaljujem se svoji druˇzini in najbliˇzjim, ki so mi vedno stali ob strani, me spodbujali, motivirali in podpirali, ter mi omogoˇcili brezskrben ˇstudij.

v

(6)
(7)

Povzetek

Testno omreˇzje brezˇziˇcnih senzorskih naprav je orodje za izvajanje raznovr- stnih eksperimentov, ki so namenjeni preizkuˇsanju novih naprav, analiziranju brezˇziˇcnih protokolov in razvijanju programske opreme. Testno omreˇzje LOG-a- TEC je primer takˇsnega instrumenta, ki ponuja uporabo 77 vozliˇsˇc, razporejenih v parku in pisarnah Instituta “Joˇzef Stefan” v Ljubljani. Omogoˇca avtomatski zagon eksperimentov na napravah in zagotavlja zanesljiv naˇcin hranjenja meritev.

Eksperimenti se izvedejo samodejno, brez interakcije uporabnika. To poslediˇcno pomeni, da uporabnik ne more vplivati na potek eksperimentalne aplikacije, kar se je v praksi izkazalo za pomanjkljivost. V magistrskem delu je predstavljen sistem za spremljanje in nadzor eksperimentov v testnem omreˇzju, s katerim je uporabniku omogoˇcen pregled nad stanjem vozliˇsˇcnih naprav v realnem ˇcasu.

Prikazana je izdelava spletnega uporabniˇskega vmesnika za opazovanje izvajanja eksperimenta. Z uporabljenim mehanizmom izmenjevanja sporoˇcil v porazdelje- nem sistemu je uporabniku omogoˇceno poˇsiljanje ukazov in prejemanje odgovo- rov. Ponujen mu je naˇcin zagona, ustavitve in ponovnega zagona eksperimenta ter ponastavitev in reprogramiranje naprav v testnem omreˇzju. Na podlagi dveh eksperimentov je ovrednoteno delovanje predstavljenega sistema. Izkazal se je za uporabno orodje, ki uporabnikom olajˇsa raziskovalno delo. Z razˇsiritvijo funkci- onalnosti je testno omreˇzje pridobilo na uporabnosti brez spremembe osnovnega koncepta. Ohranilo je naˇcin samodejnega zagona in pridobivanja povratnih infor- macij po koncu eksperimenta, dodana pa mu je moˇznost nadzora stanja naprav in celotnega testnega omreˇzja med potekom eksperimentov.

Kljuˇcne besede: testno omreˇzje, brezˇziˇcna senzorska omreˇzja, spremljanje v realnem ˇcasu, vgrajeni sistemi, porazdeljeni sistemi

vii

(8)
(9)

Abstract

A wireless sensor network testbed is a tool for performing a variety of experiments, which are intended to test new devices, to analyze wireless protocols, and to de- velop software. The LOG-a-TEC testbed is an example of such an instrument. It offers the use of 77 nodes located in the park and offices of the Joˇzef Stefan Insti- tute in Ljubljana. It enables automatic deployment of experiments and provides a reliable way to store the measurements. The experiments are performed au- tomatically, without a user interaction. Consequently, the user cannot influence the course of the experimental application, which in practice turned out to be a drawback. This master’s thesis presents an experiment monitoring and control system, which allows the user to view the status of all nodes in real time. It also shows the development of a web user interface intended to observe the execution of the experiment. With the message exchange mechanism in the distributed system, the user can send commands and receive device responses. The user can start, stop or restart the experiment, and reset or reprogram the devices in the testbed. Based on the two experiments the operation of the presented system is evaluated. The system proved to be a useful tool that facilitates research work for users. With the expansion of its functionality, the testbed gained in usability without a change of the basic concept. It retained the automatic experiment deployment and a way of receiving experiment results. The testbed was added the ability to monitor the status of devices during the course of experiments.

Key words: testbed, wireless sensor networks, real time monitoring, embedded systems, distributed systems

ix

(10)
(11)

Vsebina

1 Uvod 1

1.1 Testno omreˇzje . . . 2

1.2 Testna omreˇzja brezˇziˇcnih senzorskih naprav . . . 3

1.3 Upravljanje s testnimi omreˇzji . . . 6

1.4 Nadzor nad potekom eksperimenta v realnem ˇcasu . . . 8

1.5 Sorodna dela . . . 9

1.6 Struktura magistrskega dela . . . 10

2 Testno omreˇzje LOG-a-TEC 11 2.1 Vgrajeni raˇcunalnik SNA-LGTC . . . 14

2.2 Razvojna platforma VESNA . . . 16

3 Upravljanje testnega omreˇzja LOG-a-TEC 19 3.1 Upravljanje z vozliˇsˇci s sistemom IMBA . . . 19

3.2 Avtomatski zagon eksperimentov . . . 20

3.2.1 Vsebnik Docker . . . 23 xi

(12)

3.2.2 Avtomatizacija z Ansible . . . 24

3.2.3 Zagon z GitHub Webhook . . . 25

4 Razˇsiritev funkcionalnosti testnega omreˇzja LOG-a-TEC 27 4.1 Analiza zahtev . . . 28

4.2 Zasnova in uporabljene tehnologije . . . 29

4.2.1 Izmenjevanje sporoˇcil . . . 30

4.2.2 Spletni vmesnik . . . 31

4.3 Sistem za spremljanje in nadzor eksperimentov . . . 33

4.3.1 Spletna aplikacija . . . 35

4.3.1.1 Struktura spletne strani . . . 38

4.3.1.2 Oblikovanje in slog spletne strani . . . 40

4.3.1.3 Dinamiˇcen prikaz spletne strani . . . 41

4.3.1.4 Komunikacija preko protokola WebSocket . . . . 42

4.3.2 Streˇzniˇska aplikacija . . . 44

4.3.2.1 Posredovanje statiˇcnih datotek . . . 44

4.3.2.2 Komunikacija s spletno aplikacijo . . . 45

4.3.2.3 Posredovanje sporoˇcil med krmilnikom in streˇzniˇsko aplikacijo . . . 46

4.3.3 Krmilnik sistema za nadzor eksperimentov . . . 47

4.3.3.1 Izmenjevanje sporoˇcil s pomoˇcjo knjiˇznice ZeroMQ 47 4.3.3.2 Veˇc delna sporoˇcila z ZeroMQ . . . 48

(13)

Vsebina xiii

4.3.3.3 Delovanje krmilnika . . . 49

4.3.3.4 Podatkovna baza . . . 50

4.3.4 Eksperimentalna aplikacija . . . 52

4.3.4.1 Nit klient . . . 53

4.3.4.2 Eksperiment z vgrajenim raˇcunalnikom LGTC . . 54

4.3.4.3 Eksperiment s platformo VESNA . . . 55

4.3.4.4 Operacijski sistem Contiki-NG . . . 56

4.4 Vkljuˇcitev v sistem IMBA . . . 60

4.4.1 Vkljuˇcitev v sistem avtomatskega zagona eksperimentov . 60 4.4.2 Vkljuˇcitev v SMS portal . . . 61

5 Prikaz delovanja 63 5.1 Eksperiment Bluetooth z infrastrukturno napravo SNA-LGTC . . 63 5.2 Testiranje omreˇzja 6TiSCH z eksperimentalno napravo VESNA . 65

6 Sklepne ugotovitve in zakljuˇcek 71

Literatura 73

(14)
(15)

Seznam slik

1.1 Testno omreˇzje brezˇziˇcnih senzorskih naprav (dvo stopenjska arhi-

tektura). . . 3

1.2 Testno omreˇzje heterogenih brezˇziˇcnih senzorskih naprav (ˇstiri sto- penjska arhitektura). . . 4

2.1 Postavitev vozliˇsˇc v parku (levo) in primer postavitve vozliˇsˇcnih naprav na drog uliˇcne svetilke - poloˇzaj 6 (desno). . . 12

2.2 Arhitektura testnega omreˇzja LOG-a-TEC. . . 13

2.3 Vozliˇsˇcna naprava v testnem omreˇzju LOG-a-TEC. . . 14

2.4 Vgrajeni raˇcunalnik SNA-LGTC. . . 15

2.5 Povezljivost med raˇcunalnikom LGTC in platformo VESNA. . . . 15

2.6 Razvojna platforma VESNA, ploˇsˇca SNC-STM32. . . 16

2.7 Moˇzne nadgradnje osnovne ploˇsˇce SNC. . . 17

3.1 Izgled spletne strani portala SMS. . . 20

3.2 Sekvenˇcni diagram avtomatskega zagona eksperimentov. . . 22

3.3 Potek izdelave vsebnika iz datoteke Docker. . . 23

3.4 Soˇcasno izvajanje opravil s pomoˇcjo orodja Ansible. . . 24 xv

(16)

3.5 Arhitektura avtomatskega zagona eksperimentov. . . 25

4.1 Diagram idejne zasnove delovanja nadzornega sistema. . . 30

4.2 Zasnova izdelave spletnega vmesnika. . . 32

4.3 Arhitektura vgrajene razˇsiritve sistema za spremljanje in nadzor eksperimentov. . . 34

4.4 Uporabniˇski vmesnik sistema za spremljanje in nadzor eksperimen- tov. . . 35

4.5 Konˇcni avtomat vozliˇsˇcnih naprav med izvajanjem eksperimen- talne aplikacije. . . 36

4.6 Monitor za spremljanje stanj vozliˇsˇc. . . 39

4.7 Delovanje povezave preko protokola WebSocket. . . 43

4.8 Povezava med spletno in streˇzniˇsko aplikacijo. . . 44

4.9 Delovanje streˇzniˇske aplikacije. . . 46

4.10 Naˇcin izmenjevanja sporoˇcil s knjiˇznico ZeroMQ v sistemu za spre- mljanje in nadzor eksperimentov. . . 47

4.11 Sestava veˇcdelnega sporoˇcila v sistemu za nadzor eksperimentov. . 48

4.12 Komunikacija med krmilnikom in streˇzniˇsko aplikacijo. . . 50

4.13 Primer baze podatkov s stanji vozliˇsˇc. . . 51

4.14 Arhitektura eksperimentalne aplikacije: a) eksperiment z vgraje- nim raˇcunalnikom LGTC, b) eksperiment s platformo VESNA. . . 52

4.15 Vtiˇcniki ZeroMQ za proces izmenjevanja sporoˇcil. . . 53

4.16 Delovanje predloge experiment LGTC.py. . . 54

4.17 Izmenjevanje sporoˇcil med napravami preko serijske povezave. . . 56

(17)

Seznam slik xvii

4.18 Avtomatski sistem zagona eksperimentov z razˇsiritvijo. . . 61 4.19 Posredovanje zahtev uporabnika v vsebniku Sensor Managament

System. . . 62 5.1 Primer uporabniˇskega vmesnika med potekom eksperimenta loka-

lizacije s tehnologijo Bluetooth. . . 64 5.2 Primer doloˇcitve lokacije ene izmed naprav s pomoˇcjo meritev ostalih. 65 5.3 Primer urnika protokola 6TiSCH. . . 66 5.4 Realno ˇcasovna stanja vozliˇsˇc med potekom eksperimenta: a)

Uspeˇsen zagon eksperimenta in proces grajenja, b) proces pri- druˇzevanja omreˇzju 6TiSCH, c) izvajanje eksperimentalne aplika- cije, ˇc) stanje zakljuˇcene eksperimentalne aplikacije. . . 68 5.5 Primer izhodne konzole upravitelja eksperimentov med potekom

eksperimenta 6TiSCH. . . 69

(18)
(19)

Seznam tabel

2.1 Brezˇziˇcne tehnologije v testnem omreˇzju. . . 12

4.1 Seznam moˇznih ukazov v sistemu za spremljanje in nadzor ekspe- rimentov. . . 36

4.2 Stanja vozliˇsˇcnih naprav. . . 38

4.3 Primeri podprtih tipov sporoˇcil v nadzornem sistemu. . . 49

5.1 Rezultati eksperimentov s protokolom 6TiSCH. . . 67

xix

(20)
(21)

1 Uvod

Z velikim zanimanjem za brezˇziˇcni prenos podatkov, ˇse posebej na podroˇcju in- terneta stvari (ang. internet of things, IoT) in pete generacije omreˇzij (5G), se je pojavilo veliko novih izzivov, katerim danaˇsnje tehnologije niso kos [1]. Tako se na podroˇcjih industrije (ang. industrial IoT, IIoT) sreˇcujejo s prenosi podatkov v zahtevnem, ˇsumnem okolju [2]. Za zaznavanje poˇzarov, plazovnih in drugih nevarnih podroˇcij v naravi je bolj pomemben daljˇsi doseg in majhna poraba ele- ktriˇcne energije naprave, kot pa zanesljivost komunikacijskega kanala. Ravno obratno velja za komunikacije v avtomobilski industriji, kjer je zanesljivost in hitrost prenosa podatkov kljuˇcnega pomena pri upravljanju samovozeˇcih vozil.

Podobno se v medicini za opazovanje pacienta iˇsˇce naˇcine za zanesljiv in nepre- kinjen prenos podatkov [3]. V pametnih hiˇsah je zelo pomemben vidik varnosti, saj brezˇziˇcna omreˇzja predstavljajo eno izmed ˇsibkih toˇck za vdor v sistem. Za vojaˇske namene je pomembna hitra in samodejna vzpostavitev omreˇzja z kripti- ranimi povezavami. V zabavni industriji pa so vse bolj pomembne velike hitrosti prenosa za prenaˇsanje podatkov kadarkoli in kjerkoli.

V omenjenih primerih so potrebe zelo raznovrstne in poslediˇcno je zahteva po razvoju novih tehnologij in naprav vedno veˇcja. Pri izpopolnjevanju nove pro- gramske opreme in novih strojnih naprav se raziskovalci za ocenjevanje izvedbe in delovanja posluˇzujejo treh sistemov [4, stran 30]: analitiˇcni modeli, simula- cije in testna omreˇzja (ang. testbed). Analitiˇcni modeli omogoˇcajo predstavitev problema s pomoˇcjo matematiˇcnih modelov. Z njimi je moˇc doseˇci poljubno na- tanˇcnost, zahtevajo pa veliko znanja in ˇcasa. Simulacije omogoˇcajo laˇzjo izvedbo vsestranskih testiranj brez dejanskega sistema. Natanˇcnost rezultatov je odvisna od natanˇcnosti modelov, kar je ob nepredvidljivosti realnega sveta pogostokrat velik izziv. Testna omreˇzja predstavljajo prototipe realnih sistemov in poslediˇcno 1

(22)

ponujajo najboljˇsi pribliˇzek odziva sistema v realnem svetu. So pa temu pri- merno kompleksna in draga, vendar nujna za razvoj novih tehnologij. Danes so postala ˇze standarden instrument pri raziskovanju. Predstavljajo tudi most med razvojem in prodajo, saj lahko z njimi testne metode zakljuˇcimo v konˇcen izdelek.

1.1 Testno omreˇ zje

Testno omreˇzje je okolje z naprednimi orodji za testiranje znanstvenih teorij, na- prav v procesu razvoja ali razvijanju novih tehnologij. Omogoˇca izvajanje pono- vljivih in preglednih eksperimentov s katerimi lahko preuˇcimo odziv testiranca v realnem okolju. Izraz se uporablja na veˇc podroˇcjih in lahko predstavlja preprost prototip izdelka. Pri razvoju programske opreme testno omreˇzje predstavlja oko- lje za testiranje na dejanski strojni opremi ali namenskih napravah [5]. V osnovi jih delimo na prototipna in eksperimentalna testna omreˇzja [6]. Prototipna so namenjena dokazovanju nekega koncepta (ang. proof-of-concept testbeds) in raz- iskovanju posameznega podroˇcja. Eksperimentalna testna omreˇzja, podrobneje obravnavana v tem delu, so namenjena mnogim uporabnikom (ang. multi-user experimental testbed) za izvajanje raznovrstnih poskusov z radijskimi protokoli, arhitekturami, storitvami itd.

Glede na tip uporabe poznamo testna omreˇzja video kamer, omreˇzja za te- stiranje mobilnih naprav in raˇcunalniˇskih tablic [7], robotskih sistemov [8], naj- pogosteje pa se sreˇcamo z brezˇziˇcnimi senzorskimi omreˇzji (ang. wireless sensor networks, WSNs). To je skupek vgrajenih naprav z zmoˇznostjo izvajanja sen- zorskih meritev, obdelave podatkov in brezˇziˇcno komunikacijo [1][3]. Napravo v takˇsnem omreˇzju imenujemo vozliˇsˇce (ang. node). Opremljeno je lahko z najra- zliˇcnejˇsimi senzorji za zaznavanje okolja (na primer senzorji temperature, vlage, zvoka, pritiska, osvetlitve, plinov itd.) in z enim ali veˇc radijskimi moduli. Sle- dnji se lahko uporabljajo za prenos izmerjenih podatkov ali za izvajanje meritev frekvenˇcnega spektra (ang. spectrum sensing), merjenje kakovosti brezˇziˇcne po- vezave (ang. link quality estimation) in testiranje radijskih protokolov.

(23)

1.2 Testna omreˇzja brezˇziˇcnih senzorskih naprav 3

1.2 Testna omreˇ zja brezˇ ziˇ cnih senzorskih naprav

Testna omreˇzja brezˇziˇcnih senzorskih naprav (ang. wireless sensor network te- stbeds) so osnovno orodje raziskovalcev za preizkuˇsanje brezˇziˇcnih naprav in omogoˇcajo uˇcinkovite naˇcine preizkuˇsanja aplikacij, algoritmov in tehnologij [6].

Vsebujejo veliko ˇstevilo vozliˇsˇc, razporejenih v zunanjem okolju ali v notranjosti stavb, in so pogosto umeˇsˇcena v okolje s pogoji, ki jih ˇzelimo testirati (gosto poseljena obmoˇcja, tovarne, trgovine itd.). Vozliˇsˇca so med seboj povezana v razliˇcnih topologijah, vsem pa je skupno opravljanje meritev, katere posredujejo do uporabnika za nadaljnjo analizo.

Slika 1.1: Testno omreˇzje brezˇziˇcnih senzorskih naprav (dvo stopenjska arhitek- tura).

Na senzorski napravi se obiˇcajno izvaja namenski operacijski sistem (FreeR- TOS1, RIOT2, TinyOS3 itd.) in njen namen je predvsem izvajanje poskusnih meritev. Povezava z uporabnikom in predstavitev podatkov s takˇsnimi vozliˇsˇci je zaradi omejenih virov na napravah poseben izziv. Za reˇsitev tega problema so vozliˇsˇca v testnem omreˇzju povezana z opazovalcem, ki zbira meritve in jih posreduje uporabniku [9]. Opazovalec je lahko skupen veˇc napravam, kot na sliki 1.1 prikazana entiteta ponor. Povezava med njimi je pogosto oˇziˇcena, saj se

1https://www.freertos.org/

2https://www.riot-os.org/

3http://www.tinyos.net/

(24)

radijski del uporablja za poskuse (poznamo tudi izjeme) in jo pogosto imenujemo hrbtenica (ang. backbone, backchannel).

V zadnjem ˇcasu se raziskovalci posluˇzujejo heterogene reˇsitve [10], kjer je vsaka senzorska naprava povezana na svojega opazovalca. V tem primeru vo- zliˇsˇce v testnem omreˇzju arhitekturno gledano sestavljata infrastrukturni del (ang. infrastructure node, testbed specific hardware, TSH) in eksperimentalni del (ang. experimental node, device under test, DUT), kot prikazuje slika 1.2.

Prvi del predstavlja zmogljivejˇsi, pogosto po meri narejen vgrajeni raˇcunalnik, ki skrbi za shranjevanje meritev, njihovo posredovanje uporabniku in za upravljanje z eksperimentalno napravo. Drugi del je senzorska naprava z omejenimi viri, na- menjena izkljuˇcno izvajanju eksperimentov. Poslediˇcno iz take delitve loˇcimo dve omreˇzji: infrastrukturno omreˇzje (ang. management network) oziroma hrbtenica in eksperimentalno omreˇzje (ang. experimental network).

Slika 1.2: Testno omreˇzje heterogenih brezˇziˇcnih senzorskih naprav (ˇstiri stopenj- ska arhitektura).

Arhitekturo testnih omreˇzji WSN delimo v tri skupine glede na njihovo: hrb- tenico, hierarhijo in sistem za upravljanje [10]. Vrsta povezav med vozliˇsˇci (hrb- tenica) loˇci med brezˇziˇcnimi, oˇziˇcenimi in hibridnimi testnimi omreˇzji. Oˇziˇcena omreˇzja lahko za komunikacijo z uporabnikom in napajanje naprav uporabljajo povezavo USB, ethernet, serijsko povezavo in ostale [10]. Primer takˇsne je testno omreˇzje ORBIT [11], kjer naprave med seboj komunicirajo preko gigabitne ether- net povezave. V testnem omreˇzju TWIST so platforme TelosB preko povezave

(25)

1.2 Testna omreˇzja brezˇziˇcnih senzorskih naprav 5

USB povezane na usmerjevalnik [12]. Pomanjkljivost oˇziˇcenih omreˇzij je odvisnost poloˇzaja naprav od statiˇcnega prikljuˇcka, kar onemogoˇca izvajanje eksperimentov z mobilnimi vozliˇsˇci. Temu izzivu so kos brezˇziˇcna testna omreˇzja, katerih naj- pogosteje uporabljena tehnologija za komunikacijo med vozliˇsˇci je IEEE 802.11 WLAN (v nadaljevanju Wi-Fi) [10], lahko pa uporabljajo tudi druge tehnologije, kot na primer Bluetooth [13]. Problem mobilnosti v brezˇziˇcnih testnih omreˇzjih predstavlja napajanje naprav, kar lahko reˇsimo z uporabo baterij ali sonˇcne ener- gije, kot so to naredili v testnem omreˇzju Trio [14].

Glede na hierarhijo loˇcimo med: dvostopenjskimi, tristopenjskimi ali ˇstiristopenjskimi arhitekturami testnega omreˇzja [10]. Vsako testno omreˇzje ima vsaj dve stopnji. Spodnjo predstavljajo eksperimentalne naprave, zgornjo opazovalec za interakcijo z uporabnikom (slika 1.1). Primer tovrstne arhitek- ture predstavlja Monarch Project - eno izmed prvih testnih omreˇzij z uporabo brezˇziˇcnih senzorskih naprav. ˇSest vozliˇsˇc na premikajoˇcih se vozilih je komunici- ralo z dvema pritrjenima napravama, kateri sta meritve posredovali bazni postaji (uporabniku) [10]. Tri stopenjska arhitektura je podobna dvo stopenjski, s tem da je opazovalec zmogljivejˇsa raˇcunalniˇska naprava, pogosto imenovana streˇznik za upravljanje (ang. management server). Poleg zbiranja meritev je njegova na- loga tudi upravljanje z vozliˇsˇci [10]. Primer takˇsne arhitekture predstavlja testno omreˇzje MoteLab, kjer streˇznik preko ethernet povezave upravlja z senzorskimi napravami MICAz [15]. Arhitekture ˇcetrte stopnje uporabljajo heterogena vo- zliˇsˇca. Tovrstna reˇsitev je bolj univerzalna in omogoˇca laˇzjo razˇsiritev testnega omreˇzja z novimi tehnologijami, saj lahko na isto infrastrukturno napravo prepro- sto priklopimo novo eksperimentalno napravo. Hkrati predstavlja bolj stabilen sistem, saj se s tem izognemo teˇzavam, ki nastanejo na eksperimentalnih napra- vah, ki so pogosto nagnjene k pojavitvi napak [16]. Primer takˇsne arhitekture uporablja testno omreˇzje SANDbed [17]. V njem lahko infrastrukturne naprave SNMD upravljajo in reprogramirajo eksperimentalne naprave ter nadzirajo nji- hovo porabo elektriˇcne energije. V testnem omreˇzju Kansei enojni raˇcunalnik Stargate kot infrastrukturna naprava upravlja z eksperimentalnimi napravami XSM, s katerimi se izvaja eksperimente v 433 MHz frekvenˇcnem obmoˇcju [18].

Podobno je vozliˇsˇce v testnem omreˇzju LOG-a-TEC sestavljeno iz infrastrukturne naprave LGTC in eksperimentalne naprave VESNA [16], podrobneje predsta- vljena v nadaljevanju.

(26)

1.3 Upravljanje s testnimi omreˇ zji

Kot eksperimentalno orodje mora biti testno omreˇzje tako fleksibilno za izvedbo najrazliˇcnejˇsih eksperimentov kot tudi enostavno za uporabo. Predstavljeno mora biti kot okolje, ki omogoˇca kontrolirano izvedbo eksperimentov za analizo podat- kov in algoritmov. Osnovne zahteve, ki so zaˇzelene pri vsakem testnem omreˇzju, so:

• Uvajanje sprememb v arhitekturo testnega omreˇzja mora biti preprosto.

Hiter razvoj radijskih sprejemnikov in senzorskih naprav zahteva enostavno zamenjavo in nadgradnjo vozliˇsˇc.

• Radijske motnje v okolju imajo velik vpliv na brezˇziˇcna omreˇzja, kar mora biti upoˇstevano pri postavitvi naprav v testnem omreˇzju. Za testiranje radijskih tehnologij v realnem okolju se priˇcakuje, da bo testno omreˇzje postavljeno v dejanskem realnem okolju. Zagotovljen mora biti tudi stalen in neomejen vir napajanja.

• Uporaba testnega omreˇzja mora biti dostopna globalno. Oddaljen dostop do naprav za posodabljanje programske opreme vozliˇsˇc je bistvenega pomena za raziskovanje novih tehnologij.

• Testno omreˇzje mora omogoˇcati nadzor nad stanjem vozliˇsˇc in njihovimi viri (baterije, pomnilnika, povezave itd.) [6]. Zaˇzeleno je, da se do nadzor- nega sistema dostopa iz enega mesta z upoˇstevanjem varnosti, na primer z avtentikacijo uporabnikov.

• Uporabnik lahko z napravami eksperimentira preko razvrˇsˇcevalnika, v ka- terem doloˇci opravilo, ki se ob doloˇcenem ˇcasu izvede, ali pa z neposrednim dostopom do naprave [6]. V obeh primerih mora testno omreˇzje ponujati urnik za dodeljevanje dostopa do naprav, saj na isti napravi (navadno) ne moremo izvajati veˇc eksperimentov hkrati.

• Izvedba eksperimenta na vsakem vozliˇsˇcu posebej je naporno in zamudno opravilo, zato mora testno omreˇzje zagotavljati naˇcin zagona eksperimenta na vseh napravah hkrati. Postopek je lahko za boljˇso uporabniˇsko izkuˇsnjo

(27)

1.3 Upravljanje s testnimi omreˇzji 7

avtomatiziran, omogoˇcati pa mora sprotno izbiro vozliˇsˇc vkljuˇcenih v eks- periment [10].

• Testno omreˇzje mora ponujati sofisticirana orodja za shranjevanje rezulta- tov opravljenih meritev. Sistem mora meritve zbrati in jih vrniti uporabniku med samim delovanjem ali po koncu eksperimenta. Za boljˇso uporabniˇsko izkuˇsnjo so lahko ponujeni naˇcini vizualizacije meritev v realnem ˇcasu.

• Veliko testov zahteva tehnike ponovljivosti: veˇckratna ponovitev eksperi- menta v istih pogojih mora vrniti podobne rezultate. Za izvajanje komple- ksnejˇsih eksperimentov je uporabniku lahko ponujena moˇznost spreminja- nja poteka eksperimenta med samim delovanjem (na primer z ustavitvijo aplikacije, uvedbo natanˇcnih nastavitev (ang. fine-tune) in nadaljevanjem aplikacije) [10].

• Za vrednotenje eksperimentov in potrjevanje delovanja je zaˇzelen realno ˇ

casovni monitor za nadzor stanj naprav med potekom eksperimenta. Po- nujena mora biti tudi moˇznost enostavnega zagona, ustavitve in ponovnega zagona eksperimenta kadarkoli med uporabo [6], ter moˇznost vklopa in iz- klopa naprave.

Za upravljanje in vzdrˇzevanje testnih omreˇzji raziskovalci uporabljajo razliˇcne naˇcine in razna orodja, velikokrat razvita po meri za vsako arhitekturo testnega omreˇzja posebej. Pogosto temeljijo na konvencionalnih sistemih za upravljanje z omreˇzji [10]. Zadolˇzena so za nadzor stanj naprav z zbiranjem podatkov de- lovanja (nivo baterije, moˇc povezave, topologija omreˇzja itd.), za posodabljanje programske opreme naprav in za izvajanje eksperimentov. Nekateri sistemi po- nujajo avtomatizacijo opravil in s tem uporabnikom olajˇsajo uporabo testnega omreˇzja. V [19] je predstavljen obˇsiren nabor tovrstnih orodij. V testnem omreˇzju TWIST so na primer vozliˇsˇca nadzorovana preko sistema CONECT, ki omogoˇca reprogramiranje naprav in nadzor nad njimi, dostop do njega pa je urejen preko spletne strani [12]. Za izvajanje eksperimentov v testnem omreˇzju PlanetLab lahko uporabniki zaprosijo za uporabniˇski raˇcun, s katerim dobijo dostop do sis- tema GENIWrapper za upravljanje s senzorskimi vozliˇsˇci [6].

Sodoben pristop je uporaba metode mikrostoritev (ang. micro-services): sis- tem, v katerem je zdruˇzenih veˇc orodij za upravljanje s testnim omreˇzjem, vsako

(28)

namenjeno svojemu opravilu. Ta orodja so veˇcinoma odprtokodna in razvijalcem sploˇsno znana pod angleˇskim izrazom “DevOps”, kar omogoˇca laˇzjo adaptacijo na sistem [20]. Takˇsen sistem mikrostoritev je obiˇcajno zdruˇzen v okvir (ang. fra- mework), katerih primeri so predstavljeni v [9] in [21]. V poglavju 3 je podrobneje opisan okvir IMBA [16].

Testno omreˇzje LOG-a-TEC zaradi modularne sestave vozliˇsˇcnih naprav omogoˇca preprosto uvedbo novih tehnologij. Postavitev testnega omreˇzja v park instituta ponuja izvajanje eksperimentov v realnem okolju. Z uporabo okvirja IMBA lahko upravljamo z napravami in njihovimi viri, jih posodabljamo in na njih izvedemo raznovrstne eksperimente. Z okvirjem pa ne moremo opazovati dinamiˇcnega spreminjanja eksperimentalnega okolja med izvedbo eksperimentov, kar nas je privedlo do izdelave razˇsiritve sistema, opisane v tem delu.

1.4 Nadzor nad potekom eksperimenta v realnem ˇ casu

Opazovanje poteka eksperimenta je temelj vsake znanstvene raziskave. Poslediˇcno bi moralo vsako testno omreˇzje kot orodje za znanstvene raziskave ponujati funk- cionalnosti za spremljanje poteka eksperimentov v realnem ˇcasu in moˇznosti opa- zovanja stanj naprav med izvajanjem. S takˇsnim sistemom lahko uporabnik v realnem ˇcasu opazuje opravljene meritve, kar mu pomaga pri nadaljnji analizi eksperimenta in hkrati zagotovi njegovo pravilno delovanje. Z ukazi lahko vpliva na potek aplikacije in jo po svojih ˇzeljah prilagaja, kar mu omogoˇca testiranje zahtevnejˇsih eksperimentov. Interaktivnost (npr. moˇznost enostavne zaustavitve in ponovnega zagona testa) olajˇsa odpravljanje napak pri razvoju in omogoˇca hitrejˇse razumevanje delovanja eksperimentalne aplikacije.

Uporabnost rezultatov eksperimenta je pogojena tudi z dobro predstavitvijo podatkov; ˇce rezultati niso prikazani jasno in preprosto, potem je ˇstudija obsojena na propad, ne glede na to, koliko truda je bilo vloˇzenega vanjo [4, stran 328]. Zato mora omenjeno orodje ponujati dober in intuitiven grafiˇcni vmesnik. Pregovor:

“slika pove veˇc kot tisoˇc besed” dobro drˇzi tudi pri znanstvenih raziskavah, saj je grafiˇcni prikaz eden izmed najbolj intuitivnih in preprostih naˇcinov analize meritev.

(29)

1.5 Sorodna dela 9

1.5 Sorodna dela

Na spletu je moˇc najti ˇstevilne sisteme za realno ˇcasovni nadzor nad senzorskimi omreˇzji, ki so namenjeni predvsem zbiranju in prikazovanju izmerjenih podatkov z dinamiˇcnimi grafi. Spletni portal ThingsBoard4ponuja vizualizacijo opravljenih meritev, naprave pa lahko nanjo poˇsiljajo podatke preko standardnih internetnih protokolov (HTTP, CoAP, MQTT) [22]. Podobne funkcionalnosti omogoˇcajo tudi Arduino Cloud5, Microsoftov oblak Azure6, oblak podjetja IBM7 in podobni.

V [23] so prikazali izdelavo namenskega spletnega monitorja za prikaz grafov z meritvami temperature in vlaˇznosti zraka ter vsebnosti ogljikovega dioksida. Vo- zliˇsˇca opravljene meritve preko tehnologije Wi-Fi poˇsiljajo na osrednjo napravo, kjer so podatki shranjeni v podatkovno bazo in posredovani na spletni portal za prikaz z dinamiˇcnimi grafi. V [24] opisujejo merjenje ˇcistoˇce vode in poˇsiljanje po- datkov preko mobilnega omreˇzja na osrednjo napravo, kjer so meritve v realnem ˇ

casu prikazane uporabniku.

Vse to so primeri monitorjev v realnem ˇcasu, namenjeni le za prikaz podat- kov, in ne omogoˇcajo univerzalnega nadzora nad potekom eksperimenta s testnim omreˇzjem in kontrolo nad vozliˇsˇci. Primer takˇsnega nadzora so razvili v testnem omreˇzju BOWL [25], ki vsebuje namensko razvit sistem sestavljen iz osrednjega upravitelja vozliˇsˇc, ki deluje kot posrednik ukazov in baza podatkov s stanji vo- zliˇsˇc. Na vozliˇsˇcnih napravah se soˇcasno z eksperimentom izvaja program, ki uveljavlja ukaze in posreduje stanja nazaj osrednjemu upravitelju. Sistem je na- pisan v jeziku Ruby in temelji na knjiˇznici Distributed Ruby8, s katero se sproˇzi metode na oddaljeni napravi (ang. remote method invocation, RMI). Podoben naˇcin upravljanja in nadzora eksperimentov so prikazali v [13], kjer lahko vo- zliˇsˇcne naprave upravljajo s pomoˇcjo klicev oddaljenih postopkov (ang. remote procedure call, RPC). Testno omreˇzje TRIANGLE, namenjeno testiranju mobil- nih aplikacij in naprav, je dostopno preko spletnega portala ali preko programa PathWave Keysight Test Automation9, preko katerega lahko uporabnik vozliˇsˇca

4https://thingsboard.io/

5https://docs.arduino.cc/cloud/iot-cloud

6https://azure.microsoft.com/en-us/overview/iot/

7https://www.ibm.com/cloud/internet-of-things

8https://www.ruby-lang.org/en/

9https://www.keysight.com/zz/en/products/software/pathwave-test-software

(30)

upravlja in v realnem ˇcasu opazuje potek eksperimenta [26]. Octopus [27] je orodje za nadzor naprav v testnem omreˇzju senzorskih naprav, na katerih se izvaja operacijski sistem TinyOS, in ponuja prikaz podatkov senzorjev in topo- logije omreˇzja naprav v realnem ˇcasu. Omogoˇca upravljanje eksperimentalnega omreˇzja in nastavitev vozliˇsˇcnih naprav s poˇsiljanjem kratkih ukazov, tako eni kot veˇcim napravam hkrati. V federaciji testnih omreˇzij FED4FIRE+ se za kreiranje eksperimentov uporablja orodje jFed Experimenter Toolkit10. Vsebuje grafiˇcni vmesnik, v katerem uporabnik doloˇci naprave, ki sodelujejo v eksperimentu, iz- bere aplikacijo in jo nato roˇcno zaˇzene. Med potekom lahko uporabnik napravam poˇsilja ukaze in prejema njihove odzive ter opazuje topologijo eksperimentalnega omreˇzja [28].

1.6 Struktura magistrskega dela

V magistrskem delu je predstavljena razˇsiritev ˇze obstojeˇcega sistema za upra- vljanje s testnim omreˇzjem LOG-a-TEC, s sistemom za spremljanje in nadzor eksperimentov v realnem ˇcasu. V uvodu so predstavljeni osnovni pojmi in na- membnosti testnih omreˇzij ter njihova delitev. Nakazan je tudi razlog, zakaj smo se za razˇsiritev odloˇcili. V poglavju 2 je predstavljena strojna oprema testnega omreˇzja LOG-a-TEC, na katerem je predstavljena implementirana razˇsiritev, ter njegova postavitev v okolje. Za laˇzje razumevanje postopka umestitve razˇsiritve je v poglavju 3 je prikazan sistem za upravljanje s testnim omreˇzjem in njegov sple- tni portal. Poglavje 4 opisuje zahteve in izpolnitve zadanih ciljev med postopnim prikazom izdelave same nadgradnje in uporabljenih orodij. V poglavju 5 je na podlagi eksperimentov podana evalvacija delovanja implementirane nadgradnje, poglavje 6 pa ob podanih moˇznih nadgradnjah zakljuˇci delo.

10https://jfed.ilabt.imec.be/

(31)

2 Testno omreˇ zje LOG-a-TEC

Vsebina magistrskega dela temelji na brezˇziˇcnem testnem omreˇzju LOG-a-TEC.

Nahaja se v parku Instituta “Joˇzef Stefan” in pokriva obmoˇcje veliko pribliˇzno 3000 kvadratnih metrov. Sestavljeno je iz 77 brezˇziˇcnih senzorskih vozliˇsˇc, razde- ljenih v zunanje in notranje testno okolje. Namenjeno je izvajanju eksperimentov za opazovanje frekvenˇcnega spektra, testiranju novih radijskih tehnologij in proto- tipnih naprav, razvoju brezˇziˇcnih protokolov in opravljanju primerjalnih meritev, testiranju strojne komunikacije med napravami, lokalizaciji naprav itd.

Testno omreˇzje je bilo v zadnjih letih veˇckrat nadgrajeno ter posodobljeno in se je izkazalo za zelo uporaben instrument [29]. S pristopi DevOps, kot je na primer mehanizem neprekinjene integracije (ang. continuous integration, CI), je v omreˇzju omogoˇceno efektivno razvijanje programske opreme [16]. Z vnosom spremembe v kodo eksperimenta se ta samodejno zbere in avtomatsko testira na dejanskih napravah, rezultate testa pa vrne uporabniku. Na podoben naˇcin, z me- hanizmom neprekinjene dostave (ang. continious deployment, CD), je omogoˇcen sistem za samodejni zagon eksperimentov, ki ponuja hitre rezultate in zanesljivo povratno informacijo raziskovalcem. Fleksibilnost testnega omreˇzja omogoˇca pri- lagajanje zahtevam uporabnika; v testno omreˇzje lahko enostavno vkljuˇcimo nove naprave, spremenimo njihovo lokacijo ali pa dodamo nov tip radijske tehnologije.

Postavitev vozliˇsˇc v parku instituta prikazuje slika 2.1. Zunanji del je se- stavljen iz 56 naprav, pritrjenih na drogove luˇci in razporejenih po pisarniˇskih okenskih policah na 2 do 9,3 metrov viˇsine. V notranjem okolju je v pisarnah dodatno razporejenih 21 naprav. Barve pik prikazujejo razliˇcne tipe radijskih teh- nologij, s katerimi je opremljeno vozliˇsˇce. Nekatere kljuˇcne informacije vozliˇsˇcnih naprav in razpoloˇzljivih tehnologij so navedene v tabeli 2.1 [16].

11

(32)

Slika 2.1: Postavitev vozliˇsˇc v parku (levo) in primer postavitve vozliˇsˇcnih naprav na drog uliˇcne svetilke - poloˇzaj 6 (desno).

Tabela 2.1: Brezˇziˇcne tehnologije v testnem omreˇzju.

Vrsta vozliˇsˇca Radio ˇcipi Obmoˇcje delovanja ˇSt. naprav

SRD A Atmel AT86RF212 868 MHz

21 zunaj

TI CC2500 2,4 GHz

SRD B Atmel AT86RF231 2,4 GHz

21 zunaj

TI CC1101 868 MHz

LPWA Semtech SX1272 868 MHz 3 zunaj

1 znotraj UWB DecaWave DW1000 3,5-6,5 GHz 11 zunaj

(6 kanalov) 20 znotraj

BLE TI WL1837 2,4 GHz 56 zunaj

21 znotraj

Arhitektura testnega omreˇzja LOG-a-TEC spada v kategorijo ˇcetrte stopnje.

Vozliˇsˇce v testnem omreˇzju je sestavljeno iz dveh delov: eksperimentalna na- prava in infrastrukturna naprava. Prva je zadolˇzena za izvajanje testnih aplikacij in meritev, druga pa skrbi za zagon in izvedbo eksperimentov, zbira- nje podatkov meritev in vraˇcanje le-teh uporabniku. Takˇsna delitev omogoˇca uporabo ene infrastrukturne naprave v kombinaciji z razliˇcnimi eksperimental-

(33)

13

nimi napravami, kar omogoˇca izvajanje raznovrstnih eksperimentov z enotnim sistemom upravljanja in podobno konfiguracijo [16].

Slika 2.2: Arhitektura testnega omreˇzja LOG-a-TEC.

Infrastrukturne naprave so med seboj povezane v infrastrukturnem omreˇzju in uporabniku dosegljive preko interneta. Uporabljajo tehnologijo Wi-Fi, ki deluje v 5 GHz frekvenˇcnem obmoˇcju zato, da ne povzroˇca radijskih motenj v eksperimen- talnem omreˇzju [16]. Vsa vozliˇsˇca nadzira in kontrolira skupen ponor imenovan streˇznik za upravljanje, kot prikazuje slika 2.2.

V testnem omreˇzju LOG-a-TEC se za infrastrukturno napravo uporablja vgra- jeni raˇcunalnik SNA-LGTC (opisan v podpoglavju 2.1), lahko bi pa uporabili tudi kakˇsen drugi raˇcunalnik (na primer popularen Raspberry Pi1). Eksperimentalno napravo najpogosteje predstavlja platforma VESNA (opisana v podpoglavju 2.2), nadgrajena z izbranim radijskim modulom. Za namene eksperimentiranja bi lahko uporabili tudi kakˇsno drugo napravo, na primer USB mreˇzno kartico ali pa popularno platformo Arduino2. Primer vozliˇsˇca v testnem omreˇzju LOG-a-TEC

1https://www.raspberrypi.org/

2https://www.arduino.cc/

(34)

prikazuje slika 2.3. V vodoodporno ohiˇsje je vstavljen raˇcunalnik SNA-LGTC, na katerem je pritrjena platforma VESNA, nadgrajena z radijsko ploˇsˇco ISMTV.

Slika 2.3: Vozliˇsˇcna naprava v testnem omreˇzju LOG-a-TEC.

2.1 Vgrajeni raˇ cunalnik SNA-LGTC

Vgrajeni raˇcunalnik SNA-LGTC (v nadaljevanju LGTC) je po meri izdelan enojni raˇcunalnik z moˇznostjo priklopa in kontrole razvojne platforme VESNA [30]. Raz- vit je bil v Laboratoriju za omreˇzene vgrajene sisteme (LOVS) na Institutu “Joˇzef Stefan”, Ljubljana. Njegovo jedro je modul BeagleCore3, ki temelji na ˇcipu Te- xas Instruments AM3358; to je osrednja procesorska enota (ang. central proces- sing unit, CPU) ARM Cortex-M8 s 512 MB pomnilnika z nakljuˇcnim dostopom (ang. random access memory, RAM) in 8 GB vgrajenega veˇcpredstavnostnega pomnilnika (ang. embeded multimedia controller, eMMC). Za dodaten po- mnilnik raˇcunalnik ponuja podporo za spominsko kartico mikro-SD [30]. Cipˇ WL1837MOD na vgrajenem raˇcunalniku omogoˇca brezˇziˇcno povezljivost s tehno- logijo Bluetooth in tehnologijo Wi-Fi v obmoˇcju 2,4 GHz in 5 GHz, ˇcip LAN8710 pa ponuja oˇziˇceno povezavo z ethernet omreˇzjem. Raˇcunalnik LGTC podpira tudi gostovanje naprav USB in asinhrono serijsko povezavo (ang. universal asyn-

3http://beaglecore.com/

(35)

2.1 Vgrajeni raˇcunalnik SNA-LGTC 15

chronous receiver transmitter, UART). Napajamo ga lahko z omreˇzno napetostjo (110 V / 230 V), 12 V napajalnikom ali pa preko ethernet povezave (ang. po- wer over ethernet, PoE) [30]. Za varno zaustavitev v primeru izpada elektriˇcne energije je na modulu dodana moˇznost priklopa baterije.

Slika 2.4: Vgrajeni raˇcunalnik SNA-LGTC.

Vgrajeni raˇcunalnik LGTC obiˇcajno poganja operacijski sitem Debian GNU/Linux4 in je prvotno namenjen nadzoru nad razvojno platformo VESNA.

Napravi sta med seboj povezani preko povezave UART, programiranje in od- pravljanje programskih napak pa poteka preko povezave JTAG (ang. joint test action group) [30]. Tako lahko vgrajeni raˇcunalnik iz izvorne kode zgradi (ang.

build) izvrˇsilno kodo in ji naloˇzi (ang. flash) na platformo VESNA in nato nadzira potek aplikacije preko serijske povezave.

Slika 2.5: Povezljivost med raˇcunalnikom LGTC in platformo VESNA.

(36)

2.2 Razvojna platforma VESNA

VESNA (ang. verisatile platfrom for sensor network applications) je modularna platforma, razvita v laboratoriju Sensorlab5 na Institutu “Joˇzef Stefan”, Lju- bljana, za namene testiranja in razvoja brezˇziˇcnih senzorskih omreˇzij [31].

Slika 2.6: Razvojna platforma VESNA, ploˇsˇca SNC-STM32.

Temelji na mikrokrmilniku STM32F103, ki ga poganja osrednja raˇcunalniˇska enota ARM Cortex-M3 s 64 kB statiˇcnega bralno-pisalnega pomnilnika (ang. sta- tic random access memory, SRAM) in 512 kB bliskovnega pomnilnika (ang. flash memory), ki ga lahko ˇse dodatno razˇsirimo s spominsko kartico mikro-SD [31]. Mi- krokrmilnik vsebuje razliˇcne programirljive vhodno-izhodne enote, kar omogoˇca priklop raznovrstnih senzorjev. S 16 sploˇsno namenskimi vhodno-izhodnimi spon- kami (ang. general-purpose input/output, GPIO) in digitalno analognim pretvor- nikom lahko upravljamo razliˇcne aktuatorje. Platformo lahko napajamo s 5 V napajalnikom, USB prikljuˇckom ali baterijo, podprta pa je tudi moˇznost napaja- nja s sonˇcno celico [31].

Osnova platforme je modul SNC (ang. sensor node core), na katerem se na- haja mikrokrmilnik. Nadgradimo ga lahko z razliˇcnimi razvojnimi moduli: SNE

5http://log-a-tec.eu

(37)

2.2 Razvojna platforma VESNA 17

Slika 2.7: Moˇzne nadgradnje osnovne ploˇsˇce SNC.

(ang. sensor node extension) je aplikacijska razliˇcica modula za razˇsiritev plat- forme, SNR (ang. sensor node radio) ponuja razliˇcne vrste radijskih oddajnikov in sprejemnikov. Primer razˇsiritve prikazuje slika 2.7, v nadaljevanju pa so naˇsteti nekateri izmed pomembnejˇsih modulov:

• SNE-SENS - razvojna ploˇsˇca, ki je lahko opremljena z vrsto senzorjev:

ˇ

ziroskop L3GD20, pospeˇskometer MMA8453, kompas HMC5883L, senzor temperature TMP75, vlage SHT21, pritiska LPS331AP, bliˇzine Si1143 in barve TCS3772.

• SNE-AQA - modul za merjenje kakovosti zraka, opremljen s senzorjem plinov Alphasense A4 AFE ter senzorjem temperature in vlage SHT21.

• SNE-ISMTV - ploˇsˇca je na voljo v veˇc razliˇcicah, namenjena merje- nju frekvenˇcnega spektra od kratkih valov do ultra kratkih valov z radii TDA18219, AT86RF231, AT86RF212, TI C11012 in TI C2500 [32].

• SNE-WLG - razliˇcne verzije ploˇsˇc omogoˇcajo komunikacijo s tehnologi- jami: Wi-Fi, GSM/GPRS in Bluetooth 4.0.

(38)

• SNR-TRX - razliˇcne verzije ploˇsˇc so opremljene radijskim modulom za komunikacijo s tehnologijami: IEEEE 802.15.4, 6LoWPAN in Bloetooth Low Energy.

• SNR-MOD- ploˇsˇca omogoˇca komunikacijo s tehnologijo ZigBee.

Aplikacije za platformo VESNA so obiˇcajno napisane v programskem jeziku C z uporabo po meri razvite programske opreme zdruˇzene v zbirko knjiˇznic ime- novano vesna-drivers. V njej so zbrani gonilnik strojne opreme zgoraj naˇstetih modulov in programski vmesniki za njihov nadzor. Namesto cikliˇcnega izvajanja programov (ang. cyclic executive) se lahko za programiranje platforme VESNA uporabljajo razni operacijski sistemi (FreeRTOS, RIOT, TinyOS ...). V testnem omreˇzju se najpogosteje uporablja Contiki-NG6, ker njegov sklad podpira komu- nikacije z novejˇsimi tehnologijami v razvoju.

6https://www.contiki-ng.org/

(39)

3 Upravljanje testnega omreˇ zja LOG-a-TEC

Vsako testno omreˇzje vsebuje sistem za nadzor in upravljanje s testnimi vozliˇsˇci.

V uvodu dela so naˇstete temeljne zahteve, ki jih mora tak mehanizem vsebo- vati: oddaljen in hkrati varen dostop do naprav, centralen nadzor nad stanjem in viri vozliˇsˇc prikazan na enem mestu, moˇznost posodobitve programske opreme in ponovnega zagona naprav ter druge. Za omogoˇcanje naˇstetega so razvijalci na Institutu “Joˇzef Stefan” naredili univerzalen sistem imenovan Infrastructure Management and Build Automation (v nadaljevanju IMBA), predstavljen v [16]

in [20] ter ocenjen v [29]. Ker se sistem uporablja tudi za upravljanje s testnim omreˇzjem LOG-a-TEC, je v nadaljevanju na kratko predstavljeno njegovo delo- vanje.

3.1 Upravljanje z vozliˇ sˇ ci s sistemom IMBA

Sistem IMBA temelji na konceptu arhitekture mikrostoritev – aplikacijski sistem sestavljen iz veˇc orodij, ki se uporablja za nadzor nad vozliˇsˇci v testnem omreˇzju in za avtomatski zagon eksperimentov. Mikrostoritve so zapakirane v vsebnike Docker1in so sestavljene iz sploˇsno znanih in pogosto rabljenih odprtokodnih oro- dij, kar uporabniku omogoˇca laˇzji pristop do uporabe in veˇcjo moˇznost adapta- cije [20]. Sistem za nadzor se izvaja na streˇzniku za upravljanje in je uporabniku dostopen preko spletnega portala Sensor Management System (v nadaljevanju SMS). Portal uporabniku ponuja interakcijski vmesnik za vsako izmed storitev,

1https://www.docker.com/

19

(40)

podpira pa tudi uporabo HTTP aplikacijskega programskega vmesnika [16].

Slika 3.1: Izgled spletne strani portala SMS.

SMS portal vsebuje register vseh naprav v testnem omreˇzju in uporabniku prikazuje informacije o njihovi strojni opremi, stanje prikljuˇcenih senzorjev in lokacijo na zemljevidu. Primer portala predstavlja slika 3.1. Infrastrukturne na- prave lahko uporabnik na daljavo upravlja z orodjem Rundeck2 in jih tako po potrebi preprosto posodobi in konfigurira. Orodje Munin3 omogoˇca nadzor nad viri vozliˇsˇc in lahko v primeru dosega kritiˇcne ravni uporabe virov (na primer pomnilnika), administratorju poˇslje opozorilno e-mail sporoˇcilo. Orodje Jenkins4 ponuja moˇznost izvajanja mehanizmov neprekinjene integracije in s tem razvijal- cem olajˇsa razvoj programske kode in novih eksperimentov. S pomoˇcjo storitve webhook lahko uporabnik sproˇzi sistem avtomatskega zagona eksperimentov, ki je podrobneje predstavljen v naslednjem podpoglavju. [16]

3.2 Avtomatski zagon eksperimentov

V testnem omreˇzju LOG-a-TEC se lahko eksperiment na vozliˇsˇcu izvede na dva naˇcina:

2https://www.rundeck.com/

3https://munin-monitoring.org/

4https://www.jenkins.io/

(41)

3.2 Avtomatski zagon eksperimentov 21

a) Eksperiment izvaja eksperimentalna naprava, infrastrukturna naprava pa skrbi za nadzor in shranjevanje podatkov. Eksperimentalna naprava med delovanjem periodiˇcno izpisuje opravljene meritve na serijsko povezavo UART, infrastrukturna naprava pa shranjuje vse informacije prejete na se- rijskem vmesniku v tekstovno datoteko.

b) Eksperiment se lahko izvede tudi samo z uporabo infrastrukturne naprave.

V tem primeru se aplikacija eksperimenta izvaja na infrastrukturni napravi in program tekom izvajanja shranjuje meritve v tekstovno datoteko.

V obeh primerih vozliˇsˇca po koncu izvajanja tekstovne datoteke posredujejo upo- rabniku. Zaradi takˇsne delitve lahko uporabnik za izvedbo testov uporabi celo vrsto kombinacij strojne opreme (opisane v poglavju 2).

Sploˇsna izvedba eksperimenta se zaˇcne pri naˇcrtovanju testne aplikacije in skripte za nastavljanje vozliˇsˇc. V slednji se nahaja seznam uporabljenih naprav, njihovih vlogah, dolˇzini eksperimenta in koliˇcino uporabljenih raˇcunalniˇskih virov.

Testna aplikacija, skripta in ostali podatki so shranjeni v eksperimentalnem repozitoriju, ki ga morajo naprave vkljuˇcene v eksperiment pred zaˇcetkom pre- jeti. Preveriti morajo tudi, ali imajo na voljo dovolj virov in ali so izpolnjene vse zahteve navedene v opisu eksperimenta, ter jih po potrebi pridobiti/namestiti.

Naprave nato zaˇzenejo eksperimentalno aplikacijo in po zakljuˇcku uporabniku vrnejo ˇzelene informacije ter sprostijo vse uporabljene vire, ki so zopet na voljo za nadaljnje eksperimente.

Testno omreˇzje je sestavljeno iz ˇstevilnih vozliˇsˇc in roˇcna izvedba eksperimen- tov na vsakem izmed njih predstavlja veˇcjo moˇznost pojavitve napak. Hkrati bi bil to zelo ˇcasovno potraten postopek in je neprimeren za veˇckratno ponavljanje eksperimentov. Sistem avtomatskega zagona eksperimentov lahko zgoraj opisano proceduro opravi z veˇcjo uˇcinkovitostjo in povsem samodejno. Vgrajen je v sistem IMBA in realiziran s pomoˇcjo storitve GitHub WebHook [33] ter orodji Ansible [34] ter Docker [35], podrobneje opisanimi v nadaljevanju. Slika 3.2 pri- kazuje sekvenˇcni diagram poteka avtomatskega zagona eksperimentov.

(42)

200, OK

pripravi okolje

git pull repozitorij

zgradi sliko Docker

zaˇzeni vsebnik

zgradi izvrˇsilno kodo

eksperiment naloˇzi izvrˇsilno kodo

END sinhroniziraj repozitorij

ustavljen vsebnik povezava SSH

pridobi meritve podatki povezava SSH WebHook

rezultati objava

Uporabnik GitHub Streznik za upravljanje Infrastrukturna naprava Eksperimentalna naprava

[collect results]

Ansible [release targets]

Slika 3.2: Sekvenˇcni diagram avtomatskega zagona eksperimentov.

(43)

3.2 Avtomatski zagon eksperimentov 23

3.2.1 Vsebnik Docker

Vsebniki Docker (ang. Docker containers) so namenjeni abstrakciji in izolaciji aplikacijskih programov od gostujoˇcega operacijskega sistema, podobno kot vir- tualni stroji. Z njihovo uporabo v avtomatskem zagonu eksperimentov infrastruk- turnim napravam ni treba namestiti vseh zahtevanih odvisnosti (ang. dependen- cies) fiziˇcno na napravo, saj so te nameˇsˇcene v vsebniku. V primeru napake v testni aplikaciji tako le-ta ne more onemogoˇciti delovanja operacijskega sistema vgrajene naprave [20]. Abstrakcija eksperimenta z vsebniki Docker omogoˇca tudi uporabno razliˇcnih infrastrukturnih naprav za izvedbo istega eksperimenta.

Slika 3.3: Potek izdelave vsebnika iz datoteke Docker.

V sistemu avtomatskega zagona eksperimentov infrastrukturna naprava pri- dobi datoteko Docker (ang. Dockerfile) iz skupne shrambe repozitorija. Z njeno pomoˇcjo zgradi sliko Docker (ang. Docker image), s katero zaˇzene vsebnik na- menjen izvajanju testne aplikacije, kot prikazuje slika 3.3. Vsebnik vsebuje vse zahtevane odvisnosti in ob zagonu samodejno starta eksperimentalno aplikacijo.

Za pohitritev grajenja vsebnikov infrastrukturne naprave uporabljajo predpo- mnilnik (ang. cache), ˇze narejeno temeljno sliko pa lahko prenesejo iz trgovine Docker Hub5, kar hkrati predstavlja enostavno distribucijo eksperimenta do vseh vozliˇsˇc [20].

5https://hub.docker.com/r/sensorlab6/vesna-tools

(44)

3.2.2 Avtomatizacija z Ansible

Ansible je temelj avtomatizacije in soˇcasnega izvajanja opravil na veˇc napravah.

Raˇcunalnik na katerem se program izvaja, se s pomoˇcjo protokola varne lupine (ang. secure shell protocol, SSH) poveˇze na vsa zahtevana vozliˇsˇca in izvede opravila navedena v t. i. skripti Ansible Playbook, kot prikazuje slika 3.4.

Slika 3.4: Soˇcasno izvajanje opravil s pomoˇcjo orodja Ansible.

Uporabljen sistem avtomatskega zagona eksperimentov vsebuje dve tovr- stni skripti, ki se izvajata na streˇzniku za upravljanje, in sta poimenovani release targets.yml incollect results.yml (glej sliko 3.5). V prvi so nave- dena opravila, ki jih izvede vsaka infrastrukturna naprava pred izvedbo ekspe- rimenta: pridobitev eksperimentalnega repozitorija iz portala GitHub, grajenje slike in zagon vsebnika Docker. V drugi so navedena opravila za lociranje opra- vljenih meritev in vrnitev le-teh uporabniku.

(45)

3.2 Avtomatski zagon eksperimentov 25

3.2.3 Zagon z GitHub Webhook

Spletni portal GitHub6 ponuja poleg shrambe kode v oblaku s podporo nad- zora razliˇcic (ang. version control) git, tudi ˇstevilna razvijalska orodja. Eno izmed njih je webhook, ki ob proˇzenju doloˇcenih dogodkov na shrambi GitHub o tem obvesti zunanje deleˇznike, kar sistem IMBA izkoriˇsˇca za zagon eksperi- mentov. Ob vsakem uporabnikovem proˇzenju nove objave na eksperimentalnem repozitoriju7, portal GitHub poˇslje HTTP zahtevo na streˇznik portala SMS. Ob prejemu zahteve streˇznik za upravljanje priˇcne izvajati zgoraj opisano skripto release targets.yml in tako avtomatiˇcno zaˇzene eksperiment. Po zakljuˇcitvi skripta collect results.yml pridobi rezultate in jih vrne na portal GitHub, kjer so dostopni uporabniku.

Slika 3.5: Arhitektura avtomatskega zagona eksperimentov.

6https://github.com/

7https://github.com/logatec3/logatec-experiment

(46)
(47)

4 Razˇ siritev funkcionalnosti testnega omreˇ zja LOG-a-TEC

Testno omreˇzje omogoˇca samodejni zagon eksperimentov in z abstrakcijo meha- nizma se uporabniku ni potrebno vmeˇsavati v potek izvedbe [20]. Na ta naˇcin lahko uporabnik zaˇzene eksperiment in preprosto poˇcaka na konec, dobi opra- vljene meritve in jih analizira. Kaj se dogaja v testnem omreˇzju med potekom eksperimenta, pa uporabnik ne ve, kar se je v praksi izkazalo za pomanjkljivo funkcionalnost. Ali je naprava dobila repozitorij s tesno aplikacijo, ali so vse ˇ

zelene naprave vkljuˇcene v eksperiment, ali je infrastrukturna naprava uspeˇsno zgradila izvrˇsilno kodo za eksperimentalno napravo, ali se aplikacija izvaja in kako se izvaja? To so samo primeri nekaterih informacij, ki so kljuˇcne pri izvajanju tudi najpreprostejˇsih eksperimentov. Uporabnik poˇzene eksperiment in ˇcaka na rezultate, nevedoˇc kaj se dejansko dogaja v testnem omreˇzju. Tako je lahko v primeru napake zaman ˇcakal veˇc ur, samo da je ugotovil, da eksperiment sploh ni deloval pravilno.

Eksperimenti izvedeni s testnim omreˇzjem morajo biti ponovljivi, zato da lahko raziskovalci veˇckrat preizkusijo isti problem v podobnem okolju. Poslediˇcno mora testno omreˇzje zagotavljati tehnike ponovljivosti oz. moˇznost izvedbe ek- sperimentov v podobnih pogojih. Realizacija takˇsnega okolja je zahtevna, saj je delovanje naprav v testnem omreˇzju odvisno od veliko spremenljivk (kakovost omreˇzne povezave, delovna temperatura, motnje v okolju itd.). Poslediˇcno je za izvedbo takˇsnega okolja potreben nadzor nad ˇcim veˇcimi spremenljivkami in potekom dogodkov v testnem omreˇzju [10]. Osnoven primer je sinhron zagon eksperimentalne aplikacije na vseh vozliˇsˇcih v testnem omreˇzju. Trenutni sis- tem omogoˇca samodejni zagon eksperimentov, vendar se zaradi razliˇcne dolˇzine

27

(48)

ˇ

casa, ki ga potrebuje posamezna infrastrukturna naprava za pripravo okolja, ek- sperimenti na napravah ne zaˇcnejo soˇcasno. Moˇznosti zaustavitve ali ponovitve eksperimenta brez ponovnega zagona testno omreˇzje tudi ne ponuja. Nekatere zagate je moˇc reˇsiti preko povezave SSH in roˇcne prekinitve poteka eksperimenta, kar je pa v primeru omreˇzja z veliko vozliˇsˇci ˇcasovno potratno opravilo, saj se mora uporabnik loˇceno povezati na vsako vozliˇsˇce.

V primeru kompleksnejˇsih eksperimentov, na primer pri testiranju komunika- cijskih protokolov, je realno ˇcasovna interaktivnost s testnim omreˇzjem kljuˇcnega pomena. Poglavitna informacija za uporabnika je na primer stanje eksperimen- talnega omreˇzja, kot so informacije o naˇcinu oblikovanja omreˇzja, vrstni red in ˇcasovni potek pridruˇzevanja naprav omreˇzju ipd. Testno aplikacijo za pre- izkuˇsanje komunikacijskih protokolov je smiselno pognati v primeru, ko so vse zah- tevane naprave del eksperimentalnega omreˇzja. Pridruˇzevanje naprav k omreˇzju je zaradi nedeterministiˇcnosti teˇzko napovedati brez realno ˇcasovne informacije o stanju vozliˇsˇcnih naprav.

Nekateri eksperimenti temeljijo na opazovanju iskane meritve med samim iz- vajanjem testa. Uporabnik je do sedaj lahko le ˇcakal na prejete rezultate in naknadno opazoval in analiziral spremembe, namesto da bi jih lahko spremljal ˇze v realnem ˇcasu.

Zgoraj naˇsteti primeri so kljuˇcni razlogi, ki so nas privedli do odloˇcitve za nadgradnjo testnega omreˇzja LOG-a-TEC. Razˇsiritev smo poimenovali: sistem za spremljanje in nadzor eksperimentov (ang. experiment controll and monitoring system, ECMS). Podrobneje je opisana v naslednjih podpoglavjih, vkljuˇcno z opisom integracije v ˇze razvit sistem IMBA.

4.1 Analiza zahtev

Za pridobivanje podatkov iz poljubnega raˇcunalniˇskega sistema poznamo me- todi [4, stran 319 - 322]: monitor strojne opreme in monitor programske opreme.

Slednja, za nas pomembna metoda, je v raˇcunalniˇski sistem lahko vgrajena kot del operacijskega sistema ali pa kot aplikacija v njem. Podatke lahko pridobimo s postopki periodiˇcnega izvajanja meritev ali z izvajanjem meritev pogojenih z

(49)

4.2 Zasnova in uporabljene tehnologije 29

dogodki v operacijskem sistemu [4, stran 319 - 322]. V obeh primerih mora biti programska oprema monitorja ˇcim krajˇsa, da ne posega v delovanje operacijskega sistema in s tem ne vpliva na eksperiment. Hkrati morajo biti meritve opravljene preudarno, ker lahko preveliko ˇstevilo meritev predstavlja preobremenitev za vire raˇcunalniˇskega sistema. Poslediˇcno se mora nadzorni del za zajem podatkov na testnem vozliˇsˇcu izvajati soˇcasno s testno aplikacijo, prednost pa mora imeti sle- dnja.

Testno omreˇzje LOG-a-TEC se uporablja v raznovrstnih eksperimentih, tako z eksperimentalnimi napravami kot z infrastrukturnimi. Nadgradnja mora biti temu primerno univerzalna in prilagodljiva. Uporabniˇski vmesnik mora biti intu- itiven in preprost za uporabo ter integriran v ˇze razvito platformo SMS. Nazorno mora prikazovati stanja naprav med izvajanjem eksperimenta (npr. naprava je aktivna oz. izkljuˇcena iz eksperimenta, izvaja aplikacijo ali pa je z izvajanjem ˇ

ze zakljuˇcila ipd.). Jasno naj bo razviden prehod med stanji z moˇznostjo pri- kaza dodatnih informacij vozliˇsˇca. Sinhron zaˇcetek delovanja eksperimentalne aplikacije na veˇc napravah lahko doseˇzemo z uvedbo ukaza za zaˇcetek izvajanja meritev. Podobno naj bodo omogoˇceni tudi ukazi za zaustavitev in ponovitve eksperimenta. Uporabniku naj bo ponujen vmesnik za interakcijo z vozliˇsˇci, s katerim lahko poˇslje ukaze eni napravi, ali veˇc napravam hkrati.

Kot vsak nadzorni sistem naj tudi ta stremi k ˇcim veˇcji odzivnosti in posoda- bljanju stanj in informacij v realnem ˇcasu. V brezˇziˇcnem omreˇzju s senzorskimi napravami je doseganje realno ˇcasovnih odzivov naprav v pravem pomenu besede praktiˇcno nemogoˇce. Brezˇziˇcen prenos sporoˇcila iz ene naprave na drugo vnaˇsa zamudo, ravno tako obdelava sporoˇcila, zato v tem primeru sistem v realnem ˇcasu razumemo bolj kot sistem, ki se odzove “brez obˇcutne zakasnitve”[36, stran 214].

4.2 Zasnova in uporabljene tehnologije

Predhodno opisane zahteve smo naslovili z naˇcrtovanjem spletnega vmesnika za prikaz stanj in mehanizmom izmenjevanja sporoˇcil med vozliˇsˇci. Spletni vmesnik uporabniku prikazuje realno ˇcasoven pregled nad stanjem vozliˇsˇc v eks- perimentu in omogoˇca poˇsiljanje ukazov ter prejemanje odgovorov ciljnih naprav.

(50)

Mehanizem izmenjevanja sporoˇcil je namenjen posredovanju informacij med upo- rabnikom in napravami. Realizirali smo ga z uporabo centraliziranega pristopa, kjer ena naprava deluje kot centralni upravitelj vseh naprav v testnem omreˇzju.

Vsebuje bazo podatkov vseh vozliˇsˇc in njihovo realno ˇcasovno stanje. Uporabni- kov ukaz se na centralni napravi obdela in prenese do izbranega vozliˇsˇca, hkrati pa naprave same posodabljajo svoje stanje s poˇsiljanjem sporoˇcil na centralno napravo, le ta pa jih posreduje uporabniku. Diagram idejne zasnove prikazuje slika 4.1.

Slika 4.1: Diagram idejne zasnove delovanja nadzornega sistema.

Ceprav smo lahko za izvedbo nadzornega sistema izbirali med veˇˇ c orodji, smo strmeli smo k uporabi ˇze uveljavljenih, kar zmanjˇsa razvojni ˇcas v primeru nadgradenj. V nadaljevanju so predstavljena izbrana orodja in utemeljitve glede na zahteve sistema.

4.2.1 Izmenjevanje sporoˇcil

Testno omreˇzje lahko predstavimo kot porazdeljen sistem (ang. distributed sy- stem), vsako vozliˇsˇce v njem pa kot svoj podsistem. Aplikacija razˇsiritve je tako porazdeljen program (ang. distributed program), ki svoje delo opravlja med veˇc raˇcunalniki hkrati.

(51)

4.2 Zasnova in uporabljene tehnologije 31

Komunikacija med porazdeljenimi sistemi lahko temelji na komunikaciji s pre- prostim poˇsiljanjem in prejemanjem sporoˇcil ali pa s klici oddaljenih postop- kov [37]. Primeri slednjih so lahko Java RMI1 ali ZeroRPC2, s katerimi lahko odjemalec v porazdeljenem sistemu preko streˇznika prikliˇce neki postopek ali me- todo. Tovrstno funkcionalnost bi lahko izkoristili za izvrˇsevanje uporabnikovih ukazov na vozliˇsˇcih, kot so to naredili v [25] in [13].

Odloˇcili smo se pa za uporabo komunikacije s sporoˇcili, kjer bo ena izmed na- prav, imenovana centralna naprava, zbirala in uporabniku posredovala sporoˇcila vseh ostalih naprav. Za namene posredovanja ukazov mora centralna naprava vzpostaviti komunikacijski kanal in ustvariti povezovalno omreˇzje za povezavo med oddajnikom in prejemnikom. Ker so vozliˇsˇca z infrastrukturnim omreˇzjem povezana v internet, lahko za povezovalno omreˇzje uporabimo omreˇzno povezavo.

Najbolj preprosto izmenjevanje sporoˇcil lahko izvedemo z internetnimi protokoli (na primer TCP, UDP ali MQTT). Odloˇcili smo se za uporabo knjiˇznice ZeroMQ3, ki je namenjena uporabi v porazdeljenih aplikacijah. Njen asinhroni naˇcin delo- vanja omogoˇca skoraj realno ˇcasovno izmenjevanje sporoˇcil med napravami in v ozadju delovanja programa skrbi za vzpostavitev ter vzdrˇzevanje komunikacij- skega kanala [38].

4.2.2 Spletni vmesnik

Uporabniˇski vmesnik predstavlja izhodno komponento sistema, ki uporabniku prikazuje potek izvajanja eksperimenta. Umestili smo ga v spletno stran portala SMS, zato smo stremeli k uporabi orodij, ki se v njem ˇze uporabljajo.

Spletno stran lahko delimo na ˇcelno (and. frontend) in zaledno (ang. backend) stran, kot prikazuje slike 4.2. Prvi del se izvaja na strani odjemalca, v brskalniku uporabnika in je namenjen prikazu podatkov ter interakciji z uporabnikom. Za razvoj ˇcelnega dela strani se najpogosteje uporabljajo oznaˇcevalni jezik HTML (ang. Hypertext Markup Language), predloge CSS (ang. Cascading Style She- ets) in programski jezik JavaScript, katerih uporabnost lahko dodatno razˇsirimo

1https://en.wikipedia.org/wiki/Java remote method invocation

2https://www.zerorpc.io/

3https://zeromq.org/

(52)

s knjiˇznicami in programskimi okvirji (ang. framework). Za izdelavo statiˇcnega dela spletne strani uporabniˇskega vmesnika smo uporabili jezik HTML in ga obli- kovali s predlogami CSS ter okvirjem Bootstrap4. Dinamiˇcen prikaz in interak- tivnost z uporabnikom smo izvedli s programom v jeziku JavaScript in knjiˇznico jQuery5.

Slika 4.2: Zasnova izdelave spletnega vmesnika.

Zaledni del spletne strani se izvaja na aplikacijskem streˇzniku, kjer se shranjeni podatki urejajo in posredujejo na ˇcelno stran. Za razvoj zalednega sistema smo izbirali med ˇstevilnimi razvitimi okvirji in programskimi jeziki ter se odloˇcili za uporabo streˇznika Flask6, predvsem zaradi univerzalnosti in preproste uporabe.

Narejen je v okolju Python in ponuja preproste metode za posredovanje spletnih vsebin brskalniku.

Zaradi zahtev po realno ˇcasovnem odzivu smo za komunikacijo med ˇcelnim in zalednim delom uporabili protokol WebSocket7. Za razliko od mehanizma SSE (ang. server sent events) ponuja vzpostavitev dvosmernega komunikacijskega kanala, s katerim lahko brskalnik in streˇznik asinhrono izmenjujeta sporoˇcila, kar poslediˇcno omogoˇca posodobitev spletne strani v primeru sprememb v zalednem delu (npr. v eksperimentu). Za implementacijo v aplikacijo na strani odjemalca smo uporabili knjiˇznico SocketIO8, v programu aplikacijskega streˇznika pa okolje Flask-SocketIO9.

4https://getbootstrap.com/

5https://jquery.com/

6https://flask.palletsprojects.com/en/2.0.x/

7https://datatracker.ietf.org/doc/html/rfc6455

8https://socket.io/

9https://flask-socketio.readthedocs.io/en/latest/

(53)

4.3 Sistem za spremljanje in nadzor eksperimentov 33

4.3 Sistem za spremljanje in nadzor eksperimentov

Arhitekturo implementirane nadgradnje prikazuje diagram 4.3. Sistem za spre- mljanje in nadzor eksperimentov je sestavljen iz ˇstirih programskih delov:

• spletna aplikacija

• streˇzniˇska aplikacija

• krmilnik

• klient

Spletnainstreˇzniˇska aplikacijaskrbita za predstavitev informacij uporab- niku in posredovanje ukazov. Krmilnik deluje kot centralna enota, namenjena posredovanju sporoˇcil med streˇzniˇsko aplikacijo in vozliˇsˇci. Programklientse iz- vaja na vozliˇsˇcu soˇcasno z eksperimentom. Entitete so podrobneje predstavljene v naslednjih podpoglavjih.

(54)

Slika 4.3: Arhitektura vgrajene razˇsiritve sistema za spremljanje in nadzor eks- perimentov.

(55)

4.3 Sistem za spremljanje in nadzor eksperimentov 35

4.3.1 Spletna aplikacija

Spletna aplikacija je umeˇsˇcena v platformo SMS kot nov jeziˇcek (zavihek) ime- novan Experiment (slo. eksperiment). Dostop do platforme je dovoljen samo potrjenim uporabnikom, ki morajo za vstop vnesti uporabniˇsko ime in geslo. Iz- delan uporabniˇski vmesnik, ki ga prikazuje slika 4.4, je razdeljen na dva dela:

Experiment Controller (slo. upravitelj eksperimenta) in Device Monitor (slo.

monitor za spremljanje stanj).

Upravitelj eksperimenta je postavljen na levo stran in se uporablja za izdajanje ukazov in prejemanje odgovorov naprav. V vrstici command (slo. ukaz) lahko uporabnik vnese ˇzeljen ukaz in ga poˇslje izbrani ciljni napravi s klikom na gumb send (slo. poˇslji). V izhodni konzoli (razdelek output (slo. izhod)) so uporabniku prikazani odzivi vozliˇsˇc na poslane ukaze. Uporabnik lahko s klikom na gumb clear output (slo. pobriˇsi izhod) poˇcisti izhodno konzolo, z opcijo auto scroll (slo.

samodejno vrtenje) pa vkljuˇci ali izkljuˇci moˇznost sledenja izhodnim vrsticam.

Slika 4.4: Uporabniˇski vmesnik sistema za spremljanje in nadzor eksperimentov.

Tabela 4.1 prikazuje nabor ukazov, ki jih sistem trenutno podpira. Uporabnik lahko za interakcijo z vozliˇsˇcnimi napravami preprosto doda nove.

(56)

Tabela 4.1: Seznam moˇznih ukazov v sistemu za spremljanje in nadzor eksperi- mentov.

Ukaz Opis

START Zaˇzene eksperimentalno aplikacijo.

RESTART Ponovno zaˇzene eksperimentalno aplikacijo.

STOP Ustavi aplikacijo. Vozliˇsˇce je uporabniku ˇse vedno na voljo.

EXIT Vozliˇsˇce ustavi z delovanjem aplikacije in zapusti eksperiment.

UPTIME Vrne ˇstevilo preteˇcenih sekund od zaˇcetka eksperimenta.

DURATION Vrne pred nastavljen ˇcas trajanja eksperimenta.

RESET Ukaz ponovno zaˇzene eksperimentalno napravo VESNA.

FLASH Ukaz (ponovno) naloˇzi izvrˇsilno kodo na napravo VESNA.

Monitor za spremljanje stanj vozliˇsˇc, postavljen na desno stran uporabniˇskega vmesnika, prikazuje tloris testnega omreˇzja v parku Instituta “Joˇzef Stefan” in re- alno ˇcasovno stanje vozliˇsˇc v njem. Kot primer slika 4.4 prikazuje vse poloˇzaje na- prav, ki se ujemajo z dejansko prostorsko postavitvijo v testnem omreˇzju. Ikone, ki oznaˇcujejo vozliˇsˇca, se dinamiˇcno prikazujejo glede na to, katero vozliˇsˇce sode- luje v testnem eksperimentu. Barve ikon uporabniku povedo, v katerem stanju je naprava.

Slika 4.5: Konˇcni avtomat vozliˇsˇcnih naprav med izvajanjem eksperimentalne aplikacije.

Konˇcni avtomat (ang. state machine) na sliki 4.5 prikazuje osnovna stanja

(57)

4.3 Sistem za spremljanje in nadzor eksperimentov 37

vozliˇsˇcne naprave med izvajanjem eksperimenta in prehode med njimi. Krogci prikazujejo stanja, ikone v njem pa nakazujejo barve, ki se prikazujejo na mo- nitorju za nadzor vozliˇsˇc. Pridruˇzitev naprave k eksperimentu nakazuje zaˇcetno stanje ONLINE. V primeru testa z eksperimentalno napravo zaˇcne infrastrukturna naprava samodejno izvajati proces gradnje izvrˇsilne kode (ang. build), kar nakaˇze s prehodom v stanje COMPILING. Ko binarno kodo uspeˇsno naloˇzi (ang. flash) na eksperimentalno napravo, vozliˇsˇce preide nazaj v stanje ONLINE. Za tem na- prava ˇcaka uporabnikov ukaz START in ob prejemu preide v stanje RUNNING. V njem naprava izvaja eksperimentalno aplikacijo do njene zakljuˇcitve, kar oznani z dogodkom END in prehodom v stanje FINNISHED. ˇCe med izvajanjem prejme uporabnikov ukaz STOP, se prestavi v stanje STOPPED, ukaz RESTART pa ponovno zaˇzene eksperimentalno aplikacijo. Naprave se lahko iz poljubnega stanja vrnejo v zaˇcetno stanje ONLINE z izvedbo ukaza RESET, ki ob eksperimentu z eksperi- mentalno napravo le to tudi ponovno zaˇzene. Naprave lahko med delovanjem kadarkoli prejmejo ukaz EXIT in zakljuˇcijo z eksperimentom, uporabniku pa to prikaˇzejo s prehodom v stanje OFFLINE. To predstavlja zakljuˇceno stanje in je namenjeno samo konˇcni analizi eksperimenta, ker uporabniku ponuja pregled na- prav, ki jih je nazadnje uporabljal. Iz stanjaOFFLINEse naprave lahko prestavijo samo s ponovnim zagonom celotnega eksperimenta. Zaradi laˇzje predstavitve prikazani konˇcni avtomat ne vsebuje stanj, v katera se lahko vozliˇsˇcna naprava prestavi v primeru pojave napak med izvajanjem. V ta stanja gre lahko vozliˇsˇcna naprava kadarkoli, podrobnejˇsi opis pa podaja tabela 4.2.

Tako kot ukaze lahko uporabnik enostavno dodaja tudi nova stanja naprav.

Za namene spremljanja naprave v testnem omreˇzju 6LoWPAN10 z operacijskim sistemom Contiki-NG smo na primer naknadno dodali ˇse moˇzna stanja:

• JOINED NETWORK - nakazuje, da je naprava del testnega omreˇzja,

• EXITED NETWORK - nakazuje, da je naprava zapustila testno omreˇzje,

• ROOT NETWORK - identificira koordinatorja testnega omreˇzja.

Ta (nova) stanja so nakazana z obrobo ikone. Ikona brez obrobe pomeni, da

10https://datatracker.ietf.org/doc/html/rfc4919

Reference

POVEZANI DOKUMENTI

V dnevni sobi se nahaja infrarde i sprejemnik, ki spremlja ukaze univerzalnega daljinskega upravljalnika. Z daljinskim upravljalnikom se upravlja z razsvetljavo in žaluzijami

Torej, programi za starˇsevski nadzor omogoˇ cajo pregled nad tem, do katerih vsebin imajo uporabniki raˇ cunalnikov dostop, in omogoˇ cajo, da lahko dostop do doloˇ cenih neˇ

 ESVAC projekt (European Surveillance of Veterinary Antimicrobial Consumption) Evropski nadzor nad porabo protimikrobnih zdravil v veterinarski medicini 2010 -

Z uvedbo aplikacije v proizvodni proces želimo izboljšati časovno iskanje orodij in optimalnejšo čiščenje, s čimer zmanjšamo število zaposlenih, zboljšamo

Spletna stran je namenjena uporabniku in je edini modul, prek katerega lahko uporabnik upravlja sistem.. Predloga spletne strani je narejena po načinu odzivnega

Celostno rešitev OpenTheBrew sestavljajo uporabniški vmesnik preko mobilne aplikacije Android ter regulator PID in strežnik HTTP, ki ju poganja odprtokodna platforma Arduino

spremljanje poslovnih aktivnosti, nadzorna ploˇsˇ ca, kljuˇ cni kazalnik poslovanja, upravljanje poslovnih procesov, storitveno orientirana

Čeprav je prav znanje romskega jezika pogosto izpostavljeno kot eden izmed ključnih elementov pomoči romskega pomočnika romskim učencem, pa se romski pomočniki v šoli in vrtcu