UNIVERZA V LJUBLJANI Fakulteta za strojniˇstvo
Oddaljeno spremljanje dinamike struktur
Magistrsko delo Magistrskega ˇstudijskega programa II. stopnje Strojniˇstvo
Gregor Obreza
Ljubljana, februar 2022
UNIVERZA V LJUBLJANI Fakulteta za strojniˇstvo
Oddaljeno spremljanje dinamike struktur
Magistrsko delo Magistrskega ˇstudijskega programa II. stopnje Strojniˇstvo
Gregor Obreza
Mentor: prof. dr. Janko Slaviˇ c, univ. dipl. inˇ z.
Ljubljana, februar 2022
Zahvala
Najprej bi se rad zahvalil mentorju magistrskega dela prof. dr. Janku Slaviˇcu, ki mi je omogoˇcil izdelavo te magistrske naloge ter me s strokovnimi napotki in nasveti usmerjal skozi proces. Zahvaljujem se vsem ostalim profesorjem in asistentom Fakultete za strojniˇstvo, ki so tekom mojega ˇstudija na fakulteti znanje delili z menoj. Zahvalil bi se svojim najbliˇzjim, oˇcetu Francu in mami Mariji, ki me podpirata v mojih odloˇcitvah in sta mi omogoˇcila udoben ˇstudij, ter sestrama Ani in Maruˇsi, ki sta mi vedno pripravljeni priskoˇciti na pomoˇc. Nazadnje bi se rad zahvalil punci ˇSpeli, ki me spodbuja na moji poti in podpira moje ideje, ter vsem bliˇznjim kolegom, ki me s svojo zagnanostjo in zgledom izzovejo, da ˇzelim znati in razumeti ˇse veˇc.
vi
viii
Izvleˇ cek
UDK 004.725.4:681.5(043.2) Tek. ˇstev.: MAG II/993
Oddaljeno spremljanje dinamike struktur
Gregor Obreza
Kljuˇcne besede: Raspberry Pi internet stvari MQTT
Django
spletna aplikacija procesiranje signalov
Magistrsko delo obravnava moˇznost uporabe majhnega raˇcunalnika imenovanega Ra- spberry Pi in njegovo nadgradnjo za namene izvajanja visokofrekvenˇcnih meritev z velikim dinamiˇcnim razponom. Poleg tega preuˇci orodja in protokole na podroˇcju interneta stvari za izdelavo spletne aplikacije. V drugem delu je predstavljen naˇcin uporabe aplikacije, moˇznosti uporabnikovega spremljanja tovrstnih meritev v realnem ˇcasu ter izvedba analize signalov po ustrezni metodi, na kar se navezuje tudi predsta- vljena teorija s podroˇcja procesiranja signalov.
x
Abstract
UDC 004.725.4:681.5(043.2) No.: MAG II/993
Remote monitoring of Structural Dynamics
Gregor Obreza
Key words: Raspberry Pi Internet of Things MQTT
Django Web App
Signal processing
This master thesis deals with the possibility of using a small computer called Raspberry Pi, for the purpose of performing high-frequency measurements with a large dynamic range. Further, with the purpose of creating web application, tools and protocols in the field of the Internet of Things are presented. In the second part it is shown how the user can use developed web application to monitor measurements and perform signal analysis in real time. In addition, the theoretical background of appropriate signal processing method is presented.
xii
Kazalo
Kazalo slik . . . xv
Kazalo preglednic . . . xvii
Seznam uporabljenih simbolov . . . xix
Seznam uporabljenih okrajˇsav . . . xxi
1 Uvod . . . 1
1.1 Ozadje problema . . . 1
1.2 Cilji naloge . . . 1
2 Teoretiˇcne osnove in pregled literature . . . 3
2.1 Enota za zajemanje in obdelavo podatkov . . . 3
2.1.1 Raspberry Pi . . . 3
2.1.2 ADC in DAC nadgradnja . . . 4
2.2 Spletna aplikacija . . . 6
2.2.1 Tehnologije s podroˇcja Interneta Stvari . . . 7
2.2.1.1 MQTT protokol . . . 7
2.2.1.2 WebSocket protokol . . . 10
2.2.2 Orodja s podroˇcja razvoja spletnih aplikacij . . . 11
2.2.2.1 Django - paket za izdelavo spletnih strani . . . 11
2.2.2.2 Kontejnerizacija aplikacije . . . 15
2.2.3 Asinhrono programiranje . . . 17
2.2.3.1 Primerjava sinhronega in asinhronega programiranja . 17 2.2.3.2 Osnovni gradniki Asyncio . . . 18
2.3 Procesiranje signalov . . . 20
2.3.1 Fourierjeve vrste . . . 20
2.3.2 Spekter . . . 22
2.3.3 Analogno digitalna pretvorba . . . 23
2.3.3.1 Vzorˇcenje signala . . . 23
2.3.3.2 Diskretna Fourierjeva transformacija . . . 24
2.3.4 Oknjenje . . . 24
2.3.5 Spektralna gostota moˇci . . . 26
2.3.5.1 Kriˇzna spektralna gostota . . . 28
2.3.5.2 Metoda povpreˇcenja segmentov . . . 29
3 Izdelava spletne aplikacije in sistema za zajem . . . 33
3.1 Merilni sistem . . . 33
3.1.1 Naprava za zajem in preraˇcun meritev . . . 34
3.1.1.1 Klient za zajem meritve . . . 35
3.1.1.2 Klient za delo z datotekami . . . 36
3.1.1.3 Klient za izvedbo izraˇcuna in shranjevanje datotek . . 36
3.1.2 Povezava med napravo in spletno aplikacijo . . . 36
3.1.3 Spletna aplikacija . . . 38
3.1.3.1 Zaledni sistem aplikacije . . . 39
3.1.3.2 Zaˇcelni sistem aplikacije . . . 42
3.1.3.3 Uporaba aplikacije . . . 45
4 Primer uporabe in rezultati . . . 51
4.1 Merilni sistem . . . 51
4.2 Izvedba meritve . . . 52
4.3 Rezultati . . . 53
5 Diskusija . . . 57
6 Zakljuˇcki . . . 59
Literatura . . . 61
Priloga A . . . 63
Priloga B . . . 67
Priloga C . . . 69
xiv
Kazalo slik
Slika 2.1: Raspberry Pi 3 Model B+ [2]. . . 4
Slika 2.2: Nadgradnja HiFiBerry DAC+ ADC Pro [3]. . . 5
Slika 2.3: Delovanje MQTT protokola. Klienti so lahko naroˇcniki, zaloˇzniki ali oboje hkrati. [8]. . . 8
Slika 2.4: Zivljenjski cikel HTTP protokola [19]. . . .ˇ 10 Slika 2.5: Zivljenjski cikel WebSocket protokola [17]. . . .ˇ 11 Slika 2.6: Sestava spletne aplikacije izdelane z Django paketom [25]. . . 12
Slika 2.7: Princip delovanja Django paketa. . . 13
Slika 2.8: Osnovna funkcija Django paketa - implementacija HTTP protokola. 13 Slika 2.9: Nadgradnja Django paketa s paketom Channels, ki omogoˇca poleg HTTP ˇse implementacijo WebSocket protokola. . . 14
Slika 2.10: Veˇc kontejnerjev na enemu raˇcunalniku si delijo isti operacijski sis- tem in raˇcunalniˇske vire [28]. . . 16
Slika 2.11: Primerjava poteka opravil pri sinhroni in asinhroni izvedbi. . . 18
Slika 2.12: Pozicioniranje asinhronega programiranja glede na druge podobne metode (nitenje in multiprocesiranje). . . 18
Slika 2.13: Periodiˇcni signal x(t) s periodo Tp. . . 20
Slika 2.14: Amplitudni spekter Fourierjeve vrste. . . 22
Slika 2.15: Fazni spekter Fourierjeve vrste. . . 22
Slika 2.16: Primer moˇcnostnega spektra. . . 23
Slika 2.17: Ponazoritev vzorˇcenja signala. . . 23
Slika 2.18: Oknjenje signala s pravokotnim oknom. . . 25
Slika 2.19: Fourierjeva transformacija okna w(t). . . 25
Slika 2.20: Bartlettovo okno v ˇcasovni in frekvenˇcni domeni. . . 26
Slika 2.21: Hannovo okno v ˇcasovni in frekvenˇcni domeni. . . 26
Slika 2.22: Hammingovo okno v ˇcasovni in frekvenˇcni domeni. . . 26
Slika 2.23: Primer oknjenega nakljuˇcnega signala . . . 27
Slika 2.24: Osnova metode povpreˇcenja segmentov. . . 29
Slika 3.1: Celotni merilni sistem in njegovi sestavni deli. . . 34
Slika 3.2: (a) Drevesna struktura celotne spletne aplikacije oz. Django projekta
(b) drevesna struktura posamezne manjse aplikacije. . . 39
Slika 3.3: Prijava v spletno aplikacijo . . . 45
Slika 3.4: Seznam uporabnikovih naprav. . . 46
Slika 3.5: Zaslon za upravljanje z napravo. . . 47
Slika 3.6: Nadzorna forma za upravljanje z napravo in izvedbo meritev. . . 48
Slika 3.7: Prikaz shranjenih meritev na streˇzniku, amplitude, faznega kota in koherence frekvenˇcne prenosne funkcije. . . 49
Slika 3.8: Administrativne strani za upravljanje z modeli v podatkovni bazi. . 50
Slika 4.1: Priprava za prikaz uporabe aplikacije na enostavnem eksperimentu. 51 Slika 4.2: Indikacija, da je naˇsa naprava v pripravljenosti je zelena barva in izpisani podatki o napravi (MAC naslov, ime naprave, MQTT pot vrsta nadgradnje). . . 52
Slika 4.3: Prikaz impulza sile ter odziva strukture v ˇzivo. . . 52
Slika 4.4: Prikaz impulza sile ter odziva strukture v ˇzivo. . . 53
Slika 4.5: Prikaz frekvenˇcne prenosne funkcije nosilca za ˇsesto toˇcko. . . 54
Slika 4.6: Prikaz frekvenˇcne prenosne funkcije nosilca za ˇstirinajsto toˇcko. . . 55
Slika 4.7: Prikaz frekvenˇcne prenosne funkcije nosilca za tretjo toˇcko. . . 56
xvi
Kazalo preglednic
Preglednica 2.1: Primerjava specifikacij dveh modelov malega raˇcunalnika Ra- spberry Pi [2]. . . 5 Preglednica 2.2: Specifikacije razˇsiritvenega modula HiFiBerry DAC+ ADC
Pro [3]. . . 6
xviii
Seznam uporabljenih simbolov
Oznaka Enota Pomen
a0, an, bn / koeficienti Fourierjeve vrste
B / frekvenˇcna loˇcljivost
c0, cn, b∗n / kompleksni koeficienti Fourierjeve vrste E[x] / statistiˇcno povpreˇcje
e / Eulerjevo ˇstevilo
f Hz frekvenca
f1 Hz osnovna frekvenca
fs Hz frekvenca vzorˇcenja
j / imaginarno ˇstevilo
k / indeks frekvence
Mn / koeficient Fourierjeve vrste
P W povpreˇcna moˇc
q / ˇstevilo segmentov
Rxx / avtokorelacijska funkcija Sˆ︁xx / vzorˇcna spektralna gostota Sxx Hzg2 ocena spektralne gostote moˇci
T s perioda
Tp s dolˇzina periode ˇcasovne vrste Tr s ˇcas trajanja posameznega segmenta
t s ˇcas
V ar(x) / varianca
X(f) / amplitudna gostota
|X(f)| / amplitudni spekter
|X(f)|2 / moˇcnostni spekter
x(t) / periodiˇcni signal
∆ / ˇcasovni razmik
σ(x) / standardni odklon
ϕn / koeficient Fourierjeve vrste
τ / spominska spremenljivka
ω Hz kroˇzna frekvenca
xx
Seznam uporabljenih okrajˇ sav
Okrajˇsava Pomen
ADC analogno-digitalni pretvornik(ang. analog-to-digital converter) ALSA napredna zvoˇcna arhitektura za Linux operacijske sisteme (ang. Ad-
vanced Linux Sound Architecture)
API aplikacijski programski vmesnik (ang. Application Programming In- terface)
ASGI vmesnik spletnega streˇznika (ang. Asynchronous Server Gateway In- terface)
CDA digitalno-analogni pretvornik(ang. digital-to-analog converter) CPU centralna procesna enota (ang. central processing unit)
CSD navzkriˇzna spektralna gostota (ang. Cross-spectral Density) CSS (ang. Cascading Style Sheets)
FPF frekvenˇcna prenosna funkcija (ang. FRF – Frequency Response Func- tion)
GPIO vhodni in izhodni prikljuˇcki za sploˇsen namen (ang. General Purpose Input Output)
HTML (ang. Hyper Text Markup Language) HTTP (ang. Hypertext Transfer Protocol)
I2C sinhrona serijska komunikacija (ang. Inter-Integrated Circuit) IoT internet stvari (ang. Internet of things)
I/O vhod/izhod (ang. input/output)
IP internetni protokol (ang. Internet Protocol)
JS (ang. JavaScript)
M2M komunikacija med napravami (ang. machine to machine)
MQTT telemetriˇcni transport ˇcakajoˇcih sporoˇcil (ang. Message Queuing Te- lemetry Transport)
PSD spektralna gostota moˇci (ang. Power spectral Density) PWM pulzno-ˇsirinska modulacija (ang. Pulse-width Modulation) QoS kakovost storitve (ang. Quality of Service)
REST reprezentativni prenos stanja(ang. Representational State Transfer) RPI raˇcunalnik Raspberry Pi
SoC sistem na ˇcipu (ang. System on a chip)
SPI Sinhrona serijska podatkovna povezava (ang. Serial Peripheral Inter- face Bus)
SSH protokol za upravljanej raˇcunalnika na daljavo (ang. Secure Shell) TCP protokol za nadzor prenosa (ang. Transmission Control Protocol) THD+N vsota totalne harmonske distorzije in ˇsuma (ang. Total Harmonic
Distortion Plus Noise)
URL enoliˇcni krajevnik vira (ang. Uniform Resource Locator) USB univerzalno serijsko vodilo (ang. universal serial bus) WLAN brezˇziˇcno lokalno omreˇzje (ang. wireless local area network)
xxii
1 Uvod
1.1 Ozadje problema
Pri spremljanju dinamike struktur se meritve tipiˇcno izvajajo pri razmeroma visokih frekvencah vzorˇcenja in veliki dinamiˇcni globini analogno-digitalne pretvorbe. Vedno stremimo tudi k ˇcim veˇcji kakovosti meritev, saj pridobljene podatke ponavadi upo- rabimo za nadaljnje izraˇcune in analize. Za uˇcinkovito izvedbo tovrstnih meritev ter obdelavo podatkov je tako potrebna namenska programska in strojna oprema. In- dustrija zahteva hitre in zanesljive meritve na produktih, ki morajo biti v doloˇcenih primerih izvedene samodejno oz. enostavno kjerkoli in kadarkoli. Hkrati nam trend digitalizacije industrije ter s tem razvoj novih tehnologij na podroˇcju interneta stvari in veˇcja dostopnost relativno ugodnih majhnih raˇcunalnikov (npr. Raspberry Pi) odpira nove moˇznosti merjenja in spremljanja dinamskih meritev.
Z vidika programske opreme smo pri izvedbi kakovostnih meritev velikokrat omejeni na uporabo specifiˇcnega programa in ustreznih gonilnikov, ki so skupaj nameˇsˇceni na izbranem raˇcunalniku. Tovrstno omejenost fleksibilnosti se vedno pogosteje reˇsuje s spletnimi aplikacijami, s katerimi lahko upravljamo iz katere koli naprave, ki podpira spletni brskalnik. Kljub temu da na trˇziˇsˇcu obstajajo ˇze ˇstevilne spletne aplikacije za oddaljeno spremljanje parametrov razliˇcnih senzorjev v realnem ˇcasu, so te precej omejene, saj omogoˇcajo zajemanje in prikaz razmeroma nizke frekvence vzorˇcenja po- datkov. Pri spremljanju dinamike struktur, kjer podatke zajemamo z viˇsjo frekvenco vzorˇcenja (npr. 25 kHz, v naˇsem primeru bomo poskuˇsali zajemati do 192 kHz) in visoko dinamiˇcno globino pretvorbe iz analogne v digitalno (npr. 16-bitno ali 24-bitno) tovrstne platforme niso ustrezne.
1.2 Cilji naloge
Namen magistrske naloge je preuˇciti potencial majhnih raˇcunalnikov za izvajanje viso- kofrekvenˇcnih meritev z velikim dinamiˇcnim razponom ter posredovanje takih meritev v oblak in preuˇciti moˇznosti spremljanja takih meritev v okviru spletne aplikacije. Po- trebno je raziskati moderne tehnologije, ki nam bodo omogoˇcale pretakanje tovrstne koliˇcine podatkov v aplikacijo, pri ˇcemer se bomo osredotoˇcili predvsem na protokole, ki omogoˇcajo pretakanje podatkov v realnem ˇcasu in ki jih je moˇzno spremljati na veˇc
Uvod
napravah hkrati (vsak uporabnik, ki ima dostop do spletne aplikacije lahko spremlja in izvaja meritve). Primer takih protokolov, ki so v praksi ˇze uveljavljeni in standar- dizirani, so: MQTT, XMPP, Websockets, WebRTC.
Spletna aplikacija mora poleg prikaza vrednosti v realnem ˇcasu omogoˇcati tudi nadalj- nje izraˇcune (npr. izraˇcun FPF), shranjevanje meritev in izvoz rezultatov. Poleg tega mora biti uporabniˇski vmesnik dovolj enostaven za uporabo.
V zaˇcetku magistrske naloge so predstavljene teoretiˇcne osnove tehnologij in orodji, ki so bila uporabljena pri izdelavi aplikacije, ter teoretiˇcna izhodiˇsˇca procesiranja signa- lov. V drugem delu sledi eksperimentalni del, kjer je opisano delovanje aplikacije ter prikaz uporabe le-te na praktiˇcnem primeru. Na podlagi pridobljenih rezultatov sledita diskusija in zakljuˇcki.
2
2 Teoretiˇ cne osnove in pregled lite- rature
V naslednjem poglavju so predstavljene teoretiˇcne osnove celotnega zajemnega sistema za zajem in procesiranje podatkov. V prvem delu predstavimo enoto za zajemanje in generiranje signalov, njene lastnosti ter omejitve, v drugem delu pa spletno aplikacijo in protokole ter orodja, ki so bila uporabljena pri njeni izdelavi. V zadnjem delu poglavja spoznamo ˇse teoretiˇcno ozadje metod, uporabljenih za procesiranje signalov.
2.1 Enota za zajemanje in obdelavo podatkov
Enota za zajemanje podatkov je sestavljena iz nizkocenovnega in razmeroma zmo- gljivega malega raˇcunalnika Raspberry Pi ter njegove ustrezne nadgradnje. Izbrana kombinacija nam ne omogoˇca le 24-bit 192 kHz digitalno-analogno pretvorbo na dveh kanalih, temveˇc tudi potrebno raˇcunsko moˇc za procesiranje zajetih signalov.
2.1.1 Raspberry Pi
Raspberry Pi (RPI)je majhen, razmeroma zmogljiv nizkocenovni raˇcunalnik, ki ga je razvil Eben Upton in njegovi sodelavci z Univerze v Cambridgeu leta 2006. Nadaljnji razvoj projekta se trenutno odvija pod vodstvom dobrodelnega Britanskega podjetja pod imenom Raspberry Pi Foundation [1], katerega vodilo je pribliˇzati tehnologijo mladim po celem svetu, ter jim omogoˇciti kreativno izraˇzanje skozi raˇcunalniˇstvo in programiranje. Zaradi nizke cene in hkrati visoke zmogljivosti, dobri podpori razvijal- cev in velike odprtokodne skupnosti, pa mali raˇcunalnik Raspberry Pi ni prepoznaven le v izobraˇzevalnih vodah, temveˇc je uporabljen tudi pri razvoju ˇstevilnih industrijskih aplikacij. Nekaj takih primerov uporabe so: uporaba strojnega vida, avtomatizacija skladiˇsˇc, IoT sistemi za monitoring razliˇcnih senzorjev in drugo.
Veˇcina modelov RPI je v velikosti kreditne kartice, kot je to razvidno na sliki 2.1.
Napajajo se preko USB-micro ali USB-C prikljuˇcka, imajo audio izhod, video (HDMI) izhod, USB vhode ter priklop za Ethernet kabel. Poleg omenjenega so posebnost GPIO (ang. General Purpose Input Output) prikljuˇcki, ki raˇcunalnik naredijo ˇse posebej privlaˇcen in uporaben. Poleg enostavnih vhodnih in izhodnih pinov nam omogoˇcajo
Teoretiˇcne osnove in pregled literature
tudi pulzno ˇsirinsko modulacijo (PWM), sinhrono serijsko podatkovno povezavo (SPI), I2C povezavo in serijsko povezavo. Preko njih enostavno poveˇzemo ˇstevilne senzorje ali razˇsiritvena vezja, ki jih razmeroma enostavno sprogramiramo, da sluˇzijo naˇsi specifiˇcni aplikaciji.
USB
Ethernet
Napajanje Zaslon
Kamera Audio HDMI
GPIO
Slika 2.1: Raspberry Pi 3 Model B+ [2].
Za raˇcunalnik RPI so nam na voljo ˇstevilne distribucije Linux operacijskih sistemov. V naˇsem primeru smo uporabili najpopularnejˇsega in najbolj vzdrˇzevanega – Raspberry Pi OS, ki v osnovi bazira na Debian distribuciji. Operacijski sistem po navodilih proizvajalca [2] naloˇzimo na MicroSD kartico. Raˇcunalnik RPI nato lahko uporabljamo kot namizni raˇcunalnik (priklopimo zaslon, tipkovnico in miˇsko) ali dostopamo do njega preko SSH (ang. Secure Shell). RPI se obnaˇsa kot tipiˇcen raˇcunalnik z naloˇzenim Linux operacijskim sistemom. Najpogostejˇsa orodja in knjiˇzice so ˇze prednameˇsˇcene, ostale pa uporabnik po potrebni namesti naknadno.
Skozi leta so bile razvite ˇstevilne verzije raˇcunalnika Raspberry Pi, ki se med seboj razlikujejo predvsem po zmogljivosti procesorja in velikosti delovnega pomnilnika. V fazi testiranja smo najprej uporabljali Raspberry Pi 2 Model B, ki se je izkazal za nekoliko premalo zmogljivega, zato smo se v nadaljevanju in pri izdelavi konˇcne apli- kacije odloˇcili za uporabo Raspberry Pi 3 Model B+. V preglednici 2.1 so prikazane specifikacije obeh modelov.
2.1.2 ADC in DAC nadgradnja
Zaradi ˇsirokega podroˇcja uporabe malega raˇcunalnika RPI, ˇstevilni proizvajalci po- nujajo nadgradnje oz. razˇsiritvene module, ki jih je mogoˇce prikljuˇciti direktno na GPIO pine in z nekaj nastavitvami, ki jih navadno poda proizvajalec, ti delujejo, kot bi bili del raˇcunalnika. V naˇsem primeru bomo spremljali dinamiko struktur, zato smo 4
Teoretiˇcne osnove in pregled literature Preglednica 2.1: Primerjava specifikacij dveh modelov malega raˇcunalnika Raspberry Pi [2].
Raspberry Pi 2 Model B Raspberry Pi 3 Model B+
Procesor ˇstiri-jedrni ARM Cortex-A7 @ 900 MHz
ˇstiri-jedrni ARM
Cortex-A53 64-bit SoC @ 1.4GHz
RAM 1 GB 1 GB
USB 4 4
WLAN Ne Da
Shramba MicroSD
Velikost [mm] 85.6 x 56.5
Cena [¿] 35 40
Leto izida 2015 2016
izbrali nadgradnjo, ki sluˇzi kot analogno-digitalni (ADC) in digitalno-analogni pretvor- nik (DAC). Na dodano enoto bo mogoˇce povezati ustrezen pospeˇskomer za meritve ali vibrator za vzbujanje strukture.
Po prvi fazi testiranja potencialnih nadgradenj za ADC in DAC pretvorbo, smo izbrali nadgradnjo HiFiBerry DAC+ ADC Proˇsvicarskega proizvajalca Modul 9 GmbH.
Njen izgled in glavni sestavni deli, ki so pomembni za uporabnika, so prikazani na sliki 2.2.
Analogni vhod
Analogni izhod
Slika 2.2: Nadgradnja HiFiBerry DAC+ ADC Pro [3].
HiFiBerry DAC+ ADC Pro nam po podatkih proizvajalca, dostopni na spletni strani [3], omogoˇca 24-bit 192 kHz digitalno-analogno pretvorbo na dveh kanalih in 24-bit 192 kHz analogno-digitalno pretvorbo prav tako na dveh kanalih. Specifikacije so predstavljene v preglednici 2.2.
Nadgradnja se primarno uporablja kot dodatna avdio kartica za raˇcunalnike RPI. Po- slediˇcno je njena namestitev dokaj enostavna, saj proizvajalec redno posodablja go- nilnike za novejˇse modele RPI. Velika prednost te kartice je tudi, da jo je mogoˇce upravljati preko ALSA mikserja (ang. ALSA mixer). ALSA, je napredna zvoˇcna arhi- tektura za Linux operacijske sisteme (ang. Advanced Linux Sound Architecture) [4], ki
Teoretiˇcne osnove in pregled literature
Preglednica 2.2: Specifikacije razˇsiritvenega modula HiFiBerry DAC+ ADC Pro [3].
Parameter Vrednost
Maksimalna vodna napetost 2.1 Vrms Maksimalna izhodna napetost 2.1 Vrms ADC razmerej signal-ˇsum 110 dB DAC razmerje signal-ˇsum 112 dB
ADC THD+N -90 dB
DAC THD+N -93 dB
Frekvenˇcni odziv 10 Hz -70 kHz Vhodno ojaˇcanje -12 dB do 32 dB
Poraba moˇci <0.3 W
Frekvenca vzorˇcenja 44.1 kHz – 192 kHz
nam zagotavlja zvoˇcno funkcionalnost na Linux operacijskih sistemih in podpira vrsto profesionalnih avdio kartic in njihovo enostavno upravljanje. V povezavi s tem obsta- jajo razvite in aktivno vzdrˇzevane knjiˇzice napisane v programskem jeziku Python, ki za osnovo uporabljajo ALSA mikser, kar nam ˇse dodatno olajˇsa sam razvoj programa za operiranje s to nadgradnjo.
Za delo z omenjeno zvoˇcno kartico bomo tako uporabili dve Python knjiˇzici. Prva je PyAudio [5], ki je dokaj enostavna in ponuja ˇstevilne metode. Princip uporabe, npr. zajemanje ali generiranje signala, temelji na ustvarjanju toka zajema, ki ga nato lahko shranjujemo v datoteko, obdelujemo ali posredujemo naprej. Najveˇcja prednost je predvsem enostavnost uporabe. Druga je knjiˇzicaPython-sounddevice[6], ki nam ponuja ˇse nekoliko veˇc moˇznosti. Dobra lastnost te knjiˇzice je, da nam lahko zajeti signal zapiˇse v obliki Numpy [7] numeriˇcnih polj. Numeriˇcna polja je veliko laˇzje uporabiti pri nadaljnjih izraˇcunih saj so optimizirana za delo z veˇcjo koliˇcino podatkov.
Knjiˇzica Python-sounddevice poleg tega omogoˇca tudi delo s surovimi podatki, ˇce to naˇsa aplikacija zahteva. Z njeno uporabo enostavno zajemamo in predvajamo signal z definiranim ˇcasom trajanja in frekvenco ali pa ustvarjamo toka vhoda ali izhoda (ang.
InputStream inOutputStream).
2.2 Spletna aplikacija
V nadaljevanju naloge bomo predstavili uporabljena orodja in tehnologije, ki smo jih uporabili pri razvoju spletne aplikacije za naˇs specifiˇcni primer. V prvem delu bodo opisani aktualni standardizirani protokoli s podroˇcja Interenta stvari (IoT), ki smo jih uporabili pri izdelavi aplikacije, ter njihove prednosti in omejitve. Drugi del bo posveˇcen predvsem Django paketu za izdelavo spletnih strani ter pristopu kontejneri- zacije (ang. dockerize) aplikacije. Poglavje zakljuˇcimo s predstavljenimi metodami za procesiranje signalov.
6
Teoretiˇcne osnove in pregled literature
2.2.1 Tehnologije s podroˇ cja Interneta Stvari
Posebnost naˇse spletne aplikacije je, za razliko od ˇze obstojeˇcih aplikacij interneta stvari (IoT), da nam mora omogoˇcati pretakanje velikega toka podatkov, ki se ustvarja pri izvajanju meritev dinamike struktur. Za zagotavljanje zanesljivosti prejemanja paketov in poenostavitvijo prikaza ter shranjevanja toka podatkov, smo se osredotoˇcili na ˇze obstojeˇce protokole, ki so zgrajeni na osnovi TCP/IP protokola. Glede na naravo naˇsega problema, smo se odloˇcili za uporabo kombinacije protokolov MQTT (ang.
Message Queuing Telemetry Transport) in WebSocket.
2.2.1.1 MQTT protokol
MQTT je popularen odprtokodni protokol za komunikacijo med napravami (M2M) na podroˇcju IoT. Prvo verzijo protokola sta leta 1999 razvila Andy Stanford-Clark in Arlen Nipper za namen spremljanja stanja naftnih cevi. Javno dostopen in ˇsirˇse uporabljen je postal po letu 2013, ko je bila verzija v3.1 uradno potrjena. Od takrat naprej se protokol aktivno nadgrajuje, razvija in uporablja na ˇstevilnih podroˇcjih interneta stvari. Po podatkih uradne spletne strani specifikacije [8], so najpogostejˇsi primeri uporabe v avtomobilski industriji, logistiki in transportu, nadzorovanju proizvodnih procesov, pametnih domovih, razliˇcnih vejah energetike ter celo v potroˇsniˇskih izdelkih (npr. male vremenske postaje). Z drugimi besedami, po opisu iz knjige [9], reˇsuje tipiˇcne izzive na podroˇcju IoT in M2M aplikacij in tako ponuja:
– enostavno poˇsiljanje podatkov med klienti,
– posredovanje velikega volumna podatkov brez pretiranih zahtev zmogljivosti sistema, – poˇsiljanje majhnih paketov v velikih koliˇcinah,
– moˇzno posluˇsanje dogodkov v primeru spremembe stanja, – podpira vedno-povezan in vˇcasih-povezan model,
– zagotavlja dostavo paketov tudi pri nezanesljivih internetni povezavi, – omogoˇca komunikacijo zelo blizu realnega ˇcasa (ang. real-time delivery), – ponuja varnost in zasebnost,
– zelo skalabilen in omogoˇca distribucijo podatkov med veˇc tisoˇc klienti.
V tem teoretiˇcnem delu bodo predstavljene osnovne funkcije in princip delovanja proto- kola, ki jih programer potrebuje za razumevanje in razvoj aplikacij in so delno povzete po knjigi [9]. Podrobnejˇse specifikacije pa so dostopne v uradnem standardu izdanemu s strani neprofitne organizacije OASIS [10].
MQTT deluje po sistemu objavi-naroˇci (ang. publish/subscribe). Pri tovrstnem sis- temu so na eni strani odjemalci oz. klienti (ang. client), med njimi pa posrednik (ang. broker). Klienti so zaloˇzniki (ang. Publisher) ali naroˇcniki (ang. Subscriber).
Zaloˇzniki pod doloˇceno temo (ang. topic) objavljajo podatke in jih posredujejo posre- dniku, naroˇcniki pa se na to temo prijavijo in podatke prejemajo preko posrednika. Za enostavnejˇso predstavo sistema si lahko ogledamo shemo 2.3.
Posrednik
Ponekod v literaturi poimenovan tudi MQTT server, je kljuˇcen gradnik MQTT sistema, ki upravlja s sporoˇcili, skrbi za varnost in avtentifikacijo klientov ter zagotavlja, da so
Teoretiˇcne osnove in pregled literature
MQTT posrednik (ang. broker) Založniki
(ang. publishers) Založniki in naročniki
(ang. publishers and subscribers) Naročniki (ang. subscribers)
Objavljanje Naročanje
Slika 2.3: Delovanje MQTT protokola. Klienti so lahko naroˇcniki, zaloˇzniki ali oboje hkrati. [8].
sporoˇcila dostavljena v skladu z doloˇcenim kakovostnim razredom. Ponavadi je posre- dnik nameˇsˇcen na zanesljivem raˇcunalniku, ki obratuje neprestano. Obiˇcajno imamo v sistemu enega posrednika, pri kompleksnejˇsih aplikacijah pa lahko pride tudi do si- tuacije, kjer jih imamo veˇc. V tem primeru je moˇzno posrednika nastaviti, da obratuje kot most (ang. bridge). Tako se torej eden izmed posrednikov do drugega obnaˇsa kot klient. Posrednika je mogoˇce nastaviti tudi tako, da sporoˇcila poˇsilja preko protokola WebSocket. To je ˇse posebej uporabno, kadar ˇzelimo sporoˇcila poˇsiljati direktno v sple- tni brskalnik, ki sam po sebi ne podpira MQTT protokola. V tem primeru se spletni brskalnik poveˇze s posrednikom preko WebSocket protokola in se obnaˇsa kot samosto- jen klient. Za namestitev posrednika je na voljo veˇc ponudnikov. V naˇsem primeru smo izbrali odprtokodnega posrednika Eclipse Mosquitto [11], ki je redno vzdrˇzevan in podprt s strani ˇstevilnih organizacij. Za testne namene in razhroˇsˇcevanje pa je na voljo tudi javno dostopen posrednik v oblaku [12].
Klient
Vsaka naprava ali aplikacija, ki se poveˇze s posrednikom in preko njega objavlja sporoˇcila (opravlja funkcijo zaloˇznika) ali se na njih le naroˇci (opravlja funkcijo naroˇcnika).
Klient je lahko tudi naroˇcnik in zaloˇznik hkrati. Klienti so tako lahko samostojni raˇcunalniki, mobilne naprave, mikrokrmilniki ali spletne aplikacije. Tudi tu je na voljo vrsta knjiˇzic za razvoj klienta v razliˇcnih programskih jezikih. Ker bomo v naˇsem pri- meru uporabljali programski jezik Python in zaradi specifiˇcne narave naˇse aplikacije (velik tok podatkov), smo izbrali knjiˇzico asyncio-mqtt [13], ki za osnovo uporablja priznano knjiˇzico Eclipse Paho [14].
8
Teoretiˇcne osnove in pregled literature Potek prijave in objave v temo
Vsak klient najprej izvede povezavo s posrednikom. Zaradi varnosti, se na podlagi posredovanega uporabniˇskega imena in gesla, ki smo ga predhodno izbrali med kon- figuracijo posrednika, opravi overitev klienta. Po uspeˇsno vzpostavljeni povezavi po- srednik drˇzi odprto povezavo s klientom, dokler je ta ne izgubi ali poˇslje kontrolni paket za zaprtje le-te. Klient se nato prijavi (ang. subscribe) na izbrano temo (ang.
topic). Teme imajo hierarhiˇcno strukturo, kjer so (/) uporabljene kot loˇcila stopenj teme. Primer bi torej bil: meritve/raspberry01/vhod01, kjer je meritve najviˇsja stopnja teme, vhod01 pa najniˇzja. Pri prijavah sta nam na voljo tudi dva nadome- stna znaka (ang. wildcards), ki poenostavita proces v primeru, da se ˇzelimo naroˇciti na veˇc tem hkrati. Plus znak (+) je enostopenjski nadomestni simbol, ki nadomesti katerokoli ime na specifiˇcni stopnji. Naroˇcilo na meritve/+/vhod01 bo tako rezul- tiralo kot naroˇcilo na vse raˇcunalnike RPI npr. meritve/raspberry01/vhod01 in meritve/raspberry02/vhod01. Drugi nadomestni znak je simbol kljuˇcnika (#), ki je veˇcstopenjski in se ga lahko uporablja le na koncu filtra teme. V tem primeru bomo naroˇceni na vse teme, katerih najviˇsja stopnja je enaka. Naroˇcilo na meritve/# torej pomeni naroˇcilo na vse teme, ki se zaˇcnejo zmeritve/. Pozorni moramo biti tudi na velike in male ˇcrke.
Kakovostni razredi
Protokol MQTT nam omogoˇca definicijo kakovosti storitve (ang. Quality of Service).
Na tem mestu je vredno omeniti, da definicija kakovostnega razreda vkljuˇcuje tako po- srednika kot klienta. Torej lahko objavljamo z neko stopnjo kakovosti in se prijavljamo (z drugim klientom) z drugaˇcno stopnjo kakovosti. V tem primeru bo posrednik prilago- dil kakovost storitve na niˇzjo zahtevano. Z izbrano stopnjo kakovosti meritve vplivamo, na kakˇsen naˇcin se preverja, ˇce je bilo sporoˇcilo uspeˇsno dostavljeno. Obstajajo sledeˇci kakovostni razredi:
– 0, dostavljeno najveˇc enkrat: Ta kakovostni razred ponuja enako garancijo kot osnovni TCP protokol na osnovi katerega je MQTT zgrajen. Sporoˇcilo ni potrjeno s strani prejemnika ali destinacije. Poˇsiljatelj le poˇslje sporoˇcilo. Sporoˇcila, ki ne prispejo na cilj so izgubljena. Glavna prednost te stopnje je, da porablja najmanj raˇcunalniˇskih virov in internetne pasovne ˇsirine.
– 1, dostavljeno vsaj enkrat: Ta kakovostni razredu doda potrditvene zahteve na strani prejemnika. Poˇsiljatelj shranjuje sporoˇcilo, dokler ne dobi potrdila, da je bilo sporoˇcilo prejeto s strani prejemnika. Zagotovi, da je bilo sporoˇcilo dostavljeno. ˇCe potrdila v specifiˇcnem ˇcasu ne prejme, le-tega poˇslje ponovno. Zavedati se moramo, da v doloˇcenih primerih lahko pride do podvojenih sporoˇcil, ki jih moramo v pro- gramu odstranjevati sami. Ta kakovostni razred tudi porabi precej veˇc raˇcunalniˇskih virov in internetne pasovne ˇsirine.
– 2, dostavljeno toˇcno enkrat: Zadnji in najstroˇzji kakovostni razred storitve zago- tavlja, da je sporoˇcilo vedno dostavljeno le enkrat. Zahteva dodaten tok informacij, ki ˇse dodatno potrdi, da je bilo sporoˇcilo prejeto s strani prejemnika natanko enkrat.
Je najbolj zahteven, kar se tiˇce virov in pasovne ˇsirine. Ponavadi se ga uporablja le v primerih, kjer nimamo stabilne internetne povezave in ˇzelimo zagotoviti, da bo sporoˇcilo kljub temu dostavljeno, ˇceprav z nekolikˇsnim zamikom.
Teoretiˇcne osnove in pregled literature 2.2.1.2 WebSocket protokol
WebSocket protokol je uradno definiran in podrobneje opisan v internetnem standardu RFC 6455 [15], ki je bil sprejet leta 2011, ko je veˇcina internetnih brskalnikov ˇze uradno podpirala protokol. V pomoˇc pri razumevanju in programiranju nam je bila knjiga av- torja A. Lombardi [16], uradna mozillina dokumentacija za razvijalce 17 in dokumen- tacija Python knjiˇzice websocket [18]. Tehnologija Websocket omogoˇca dvosmerno komunikacijo oziroma polni dupleks (ang. full-duplex), komunikacijski kanal, preko enojne TCP povezave. Tehnologija daje moˇznost izdelave aplikacije, katere stanja se posodabljajo zelo blizu realnega ˇcasa, brez ponovnega nalaganja spletne strani. ˇCeprav WebSocket uporablja HTTP kot zaˇcetni transportni mehanizem, se komunikacija med odjemalcem in streˇznikom ne konˇca, temveˇc ostane odprta. Protokol se tako mnoˇziˇcno uporablja za implementacijo klepetalnic, iger za veˇc igralcev, IoT platform, finanˇcnih aplikacij, beleˇzenj aktivnosti uporabnikov, GPS aplikacij, izobraˇzevalnih platform ...
Skratka tam, kjer v spletni aplikaciji potrebujemo osveˇzevanje v realnem ˇcasu. Na slikah 2.4 in 2.5 sta prikazana diagrama, ki prikazujeta princip delovanja klasiˇcnega HTTP v primerjavi z WebSocket protokolom.
Zahtevek
Klient Strežnik
Odgovor
Povezava zaprta
Slika 2.4: ˇZivljenjski cikel HTTP protokola [19].
Standardni HTTP protokol poteka v ˇstirih korakih. Najprej se odpre TCP povezava med odjemalcem in streˇznikom. Nato odjemalec poˇslje zahtevek (ang. request) in prejme odgovor streˇznika (ang. response) oziroma zahtevane podatke. V konˇcnem koraku se povezava zapre ali ponovno uporabi za nadaljnje zahteve.
Za razliko od HTTP, WebSocket protokol ne operira v ciklu zahtevek-odgovor. Tu se najprej preko HTTP protokola zgodi spoznavanje (ang. handshake) med streˇznikom in odjemalcem. Takrat tudi streˇznik prejme sporoˇcilo, da bo za komunikacijo uporabljen WebSocket in ne HTTP protokol. Tunel (ang. network tunnel) za dvosmerno komuni- kacijo nato ostane odprt in podatki med streˇznikom in odjemalcem tako lahko prosto prehajajo v realnem ˇcasu, dokler eden izmed njih ne zapre povezave.
10
Teoretiˇcne osnove in pregled literature
Klient Strežnik
Spoznavanje (HTTP)
Dvosmerna komunikacija (WebSocket)
Ena izmed strani zapre povezavo
Povezava se odpre
Dolgotrajna povezava
Povezava zaprta
Slika 2.5: ˇZivljenjski cikel WebSocket protokola [17].
2.2.2 Orodja s podroˇ cja razvoja spletnih aplikacij
Pri razvoju spletne aplikacije je pomembno, da se ˇze v zaˇcetnih fazah vpraˇsamo, katere dodatne funkcionalnosti poleg primarnih in najbolj kljuˇcnih so za nas pomembne. To so recimo upravljanje in avtentifikacija uporabnikov, prijazna uporabniˇska izkuˇsnja, enostavno upravljanje itd. Kot razvijalci se seveda ne ˇzelimo vedno znova ukvarjati z razvojem pogostih znaˇcilnosti, zato so na voljo ˇstevilni paketi, ki nam pohitrijo razvoj in omogoˇcijo, da se osredotoˇcimo le na naˇs specifiˇcen cilj. V naˇsem primeru je to implementacija izbranih tehnologij oz. protokolov za oddaljeno spremljanje dinamike struktur.
Eden izmed zelo popularnih in razˇsirjenih paketov za razvoj spletnih aplikacij jeDjango [20], ki ga predstavljamo v nadaljevanju. Gledano s strani objave konˇcne aplikacije, pa je pomemben tudi pristop razvoja. Tu se vse veˇc uporablja kontejnerizacija aplikacij, kjer je najveˇckrat uporabljeno orodje Docker [21] in bo prav tako predstavljeno v nadaljevanju.
2.2.2.1 Django - paket za izdelavo spletnih strani
Django [20] je eden izmed najbolj popularnih paketov za izdelavo spletnih strani in apli- kacij, ki sta ga zaˇcela razvijati S. Willison in A. Holovaty leta 2003. Ker je v celoti na- pisan v programskem jeziku Python, je hitro pridobil na popularnosti in ustvarila se je zelo moˇcna odprtokodna skupnost. Redne posodobitve, dodajanje novih funkcij in do- bra dokumentacija [22] je vodila do velike razˇsirjenosti. Kot podlaga za razvoj spletnih aplikacij ga uporabljajo nekatera veˇcja podjetja kot so Instagram, Mozilla, Bitbucket ... Omogoˇca hiter in uˇcinkovit razvoj spletnih aplikacij, je varen, skalabilen in primeren
Teoretiˇcne osnove in pregled literature
za vrsto razliˇcnih aplikacij; od enostavnih spletnih strani, socialnih omreˇzji, znanstve- nih raˇcunskih aplikacij itd. Zaradi svoje razˇsirjenosti in hitro rastoˇcega programskega jezika Python imamo na voljo tudi ˇstevilne knjiˇzice, ki omogoˇcajo razˇsiritev njegove funkcionalnosti za bolj kompleksne aplikacije. Dve izmed bolj popularnih razˇsiritvenih knjiˇzic razviti posebej za Django paket, sta Django REST framework [23] za iz- delavo aplikacijskih programskih vmesnikov (API) in Django Channels [24], ki nam omogoˇca implementacijo asinhronih protokolov v aplikacijo. Slednjega smo uporabili v naˇsi aplikaciji in bo nekoliko podrobneje opisan v nadaljevanju.
Osnovna struktura Django
Osnovna enota spletne aplikacije ustvarjene s pomoˇcjo paketa Django je projekt, ki ga sestavljajo ena ali veˇc aplikacij, kot je vidno na shemi 2.6.
Django Aplikacije
Django Projekt
Aplikacija 1 Aplikacija
2 Aplikacija
N
spletna aplikacija
Slika 2.6: Sestava spletne aplikacije izdelane z Django paketom [25].
Aplikacija znotraj projekta je samostojen del, ki naj bi opravljal eno nalogo celotnega projekta. Osnovna ideja za aplikacijami je njihova modularnost in da jih lahko znova uporabimo v drugih projektih, Django pa ˇze vkljuˇcuje nekaj aplikacij (te so na 2.6 poimenovane Django aplikacije). Te so recimo admin panel, sistem za autentifikacijo, upravljanje s statiˇcnimi datotekami, sejo, predpomnilnikom itd.
Gledano s strani arhitekture naˇcin delovanja spletne aplikacije izdelane s pomoˇcjo Django paketa opiˇsemo kot model-predloga-pogled (ang. Model-Template-View oz.
MTV). To prikazuje shema 2.7.
Na shemi 2.7 so prikazane komponente in dve regiji (stran streˇznika in stran odjemalca).
Django paket vkljuˇcuje komponente: Model, ki komunicira s podatkovno bazo, pogled, ki vrne odgovor oziroma prikaz in logiko aplikacije, ki opravlja ˇse druge naloge glede na zahtevek (npr. avtentifikacijo uporabnikov). Vse komponente sprogramiramo sami glede na zahteve in strukturo spletne aplikacije. Ko odjemalec preko brskalnika, ki prikazuje predlogo, poˇslje zahtevek, je ta poslan na stran streˇznika in obdelan v logiki pogleda (ang. view). Ta nato preko modela pridobi ustrezne podatke in vrne odgovor.
12
Teoretiˇcne osnove in pregled literature
Django Predloga
Stran odjemalca Stran strežnika
Logika Aplikacije
Model Logika Pogleda
Strežnik
Slika 2.7: Princip delovanja Django paketa.
Za pravilno usmerjanje URL poti, poskrbi Django sam po sebi. Django paket v osnovi implementira HTTP protokol oz. cikel zahtevek/odgovor 2.8. V kontrastu s prej omenjeno shemo, shema 2.9 prikazuje nadgradnjo osnovnega Django paketa s paketom Channels, ki bo predstavljen v nadaljevanju.
Spletni brskalnik
Funkcija pogleda
Spletni strežnik
HttpZahtevek HttpOdgovor
HTTPPython API
Slika 2.8: Osnovna funkcija Django paketa - implementacija HTTP protokola.
Django Channels
Uporaba knjiˇzice Channels [24] omogoˇci, da Django projekt ne podpira le HTTP proto- kola, temveˇc tudi protokole, ki zahtevajo dlje odprte povezave npr. WebSocket, MQTT ... Knjiˇzica je zgrajena na osnovi Python standarda ASGI [26]. Tako lahko v naˇsem projektu uporabimo kombinacijo sinhronih in asinhronih procesov. Za laˇzjo predstavo, kako se spremeni delovanje Django paketa, si lahko pogledamo shemo 2.9.
Teoretiˇcne osnove in pregled literature
Spletni brskalnik
Porabnik (HTTP)
Spletni/WebSocket strežnik
Plast kanala
Http sporočilo WebSocket sporočilo
Vmesniški strežnik
HttpZahtevek
HttpOdgovor
Funkcija pogleda Porabnik
(WebSocket) Procesi v ozadju
Proces delavca
HTTP Python API WebSocket Channels (ASGI)
Slika 2.9: Nadgradnja Django paketa s paketom Channels, ki omogoˇca poleg HTTP ˇse implementacijo WebSocket protokola.
Channels in ASGI razdelita prihajajoˇce povezave na dve komponenti: obseg (ang.
scope) in niz dogodkov (ang. events). Obseg je zbirka dogodkov o prihajajoˇci pove- zavi, kot je recimo pot, od kjer je bil poslan zahtevek, IP naslov WebSocketa ali ime uporabnika. Pri HTTP protokolu obseg traja le ˇcas enega zahtevka, pri WebSocket pa dokler povezava ni zaprta. Med ˇzivljenjsko dobo obsega se pojavi niz dogodkov, pri HTTP protokolu je to le sporoˇcilo z zahtevkom in odgovor, pri WebSocket pa vsi poslani in prejeti paketi s podatki, dokler se povezava ne zapre.
Osnovni sestavni del Channelsov, ki je omenjen tudi na shemi, je porabnik (ang. con- sumer). Lahko si ga predstavljamo kot majhno aplikacijo, ki upravlja z dogodki. Ko je zahtevek za povezavo prejet, Channels sledi definirani usmeritvi, najde ustreznega porabnika (ang. consumer) zahtevane povezave in zaˇzene novo kopijo le-tega. Porab- niki so torej dlje ˇziveˇci in mi skozi kodo definiramo, kako naj upravljajo z dogodki, Channels pa poskrbi, da teˇcejo ob ustreznem ˇcasu in da jih lahko vzporedno teˇce veˇc.
14
Teoretiˇcne osnove in pregled literature ˇSe eden zelo pomemben sestavni del aplikacije so tako imenovane plasti kanala (ang.
channel layer) kot je prikazano na 2.9. Te nam omogoˇcajo, da razliˇcne instance aplika- cije komunicirajo med seboj. Za primer recimo, da ˇzelimo v aplikaciji implementirati klepet. V tem primeru bo vsak uporabnik ob prijavi odprl svojo instanco aplikacije. Da bi lahko vsi uporabniki prejemali sporoˇcila, bi teoretiˇcno morali sporoˇcila shranjevati v podatkovno bazo in jih nato priklicati. Reˇsitev tega so plasti kanala, ki poskrbijo za distribucijo sporoˇcil med prijavljenimi uporabniki v realnem ˇcasu. Dodatno so lahko plasti kanala uporabljene tudi za dodatne delovne procese ali izvajanj nalog v ozadju.
S strani Djanga je Redis [27] trenutno edini podprti ponudnik plasti kanala in bo na kratko opisan v naslednjem odstavku.
Redis
Redis [27] (ang. Remote Dictionary Server) je odprtokodno orodje za shrambo podat- kovne strukture v pomnilnik in se lahko uporablja kot podatkovna baza predpomnilnika ali posrednika sporoˇcil. Ponuja nam uporabo struktur kot so nizi, seznami, mnoˇzice, slovarji itd. Posebnost Redisa je, da shranjuje nabor podatkov v raˇcunalniˇski spo- min. Poslediˇcno je njegov odzivni ˇcas pod milisekundo, kar omogoˇca obdelavo veˇc milijonov zahtevkov na sekundo in je idealna izbira zareal-time aplikacije na razliˇcnih podroˇcjih kot so IoT, finance, tehnologij in igraˇcarstvo. Za uporabo je na voljo v veˇcini programskih jezikov.
V naˇsi aplikaciji smo ga v Django Channels vkljuˇcili s pomoˇcjo knjiˇzicechannels redis.
Kot ˇze zgoraj omenjeno, je njegova naloga v naˇsi aplikaciji, da sluˇzi kot plast kanala.
Enostavneje povedano, opravlja funkcijo posrednika sporoˇcil, kot to podobno poˇcne po- srednik pri MQTT protokolu, katerega smo podrobneje opisali v poglavju 2.2.1.1MQTT protokol. Redis torej poskrbi za komunikacijo med razliˇcnimi instancami aplikacije. Ko poˇsljemo neko sporoˇcilo, je to prejeto na strani drugih porabnikov, ki posluˇsajo na istem kanalu.
2.2.2.2 Kontejnerizacija aplikacije
Docker [21] je platforma za izvajanje aplikacij v lahkih enotah imenovanih kontejnerji (ang. containers). Kako poteka delo s kontejnerji in na kakˇsen naˇcin se uporablja platforma Docker, smo si razjasnili po knjigi avtorja E. Stonemana [28].
Tako imenovani kontejnerji so se zaˇceli uporabljati na razliˇcnih podroˇcjih razvoja pro- gramske opreme, od razliˇcnih aplikacij v oblaku, do zasebne uporabe v podjetjih. Zna- nje Dockerja, ki je najbolj razˇsirjena platforma za kontejnerizacijo, je postalo kljuˇcno za razvijalce, ki se ukvarjajo z razvojem spletnih aplikacij. Kljuˇcna lastnost kontejne- rizacije aplikacije je prenosnost, kar pomeni, da ni razlike med izvajanjem aplikacije v razvojnih fazah na lokalnem raˇcunalniku in med izvajanjem aplikacije v produkcijskem okolju v oblaku. S tem se poenostavi razvoj, saj smo neodvisni od operacijskega sistema in konfiguracije programske opreme, ki jo ima posameznik oziroma ponudnik oblaka.
Druga dobra lastnost je, da vsak gradnik aplikacije operira v kontejnerju. Te skupaj povezuje virtualno omreˇzje in tako lahko med seboj komunicirajo ne da bi bili izpo- stavljeni zunanjemu okolju gostujoˇcega operacijskega sistema. To omogoˇci, da lahko strateˇsko posodabljamo in testiramo posamezne dele aplikacije, jih odstranjujemo in dodajamo. Vsak del aplikacije je definiran v Dockerfile datoteki, povezava celotne
Teoretiˇcne osnove in pregled literature
aplikacje pa v Docker Compose datoteki. Ne glede na to, kateri programski jezik uporablja doloˇcen del aplikacije ali katero tehnologijo uporabljajo naˇse podatkovne baze, razvijalec na svoj sistem namesti Docker, klonira izvorno kodo za postavitev kontejnerjev in zgradi ter zaˇzene celotno aplikacijo z enim ukazom. Za laˇzjo predstavo, kako veˇckontejnerizacija poteka, si lahko ogledamo shemo 2.10.
Računalnik
Docker
Operacijski sistem Kontejner 1
Aplikacija 1
Ime gostitelja IP naslov
Disk
Kontejner 2 Aplikacija
2
Ime gostitelja IP naslov Disk
Ime gostitelja IP naslov Disk CPU Spomin
Slika 2.10: Veˇc kontejnerjev na enemu raˇcunalniku si delijo isti operacijski sistem in raˇcunalniˇske vire [28].
Kontejner si lahko predstavljamo kot zaboj, ki vsebuje aplikacijo. V zaboju ima apli- kacija raˇcunalnik na videz zase. Ima svoje ime, IP naslov in svoj disk. Vse to so le virtualni viri, ki jih ustvari Docker. Virtualni viri, so torej logiˇcni objekti upravljani s strani Dockerja in skupaj tvorijo okolje, kjer lahko aplikacija operira.
Aplikacija znotraj zaboja ne vidi izven njega. Zaboj pa operira na raˇcunalniku, ki lahko poganja veˇc takih zabojev. Aplikacije imajo torej svoja loˇcena okolja vendar si vse de- lijo procesor, spomin in operacijski sistem gostujoˇcega raˇcunalnika. V raˇcunalniˇstvu in informatiki se velikokrat sreˇcujemo z dvema problemoma: izolacijo in gostoto. Sle- dnja pomeni, da lahko na raˇcunalniku izvajamo kar se da veliko ˇstevilo aplikacij, da izkoristimo vire, ki so na voljo. Problem tu je, da v praksi velikokrat pride do kriˇzanja verzij knjiˇzic, ki jih razliˇcne aplikacije potrebujejo za pravilno delovanje. Zato je tu tako pomembna tudi izolacija. V preteklosti se je to reˇsevalo z postavitvijo virtual- nih operacijskih sistemov, kar pa je bilo z vidika procesorske moˇci precej potratno in neuˇcinkovito. Kontejner uporablja le operacijski sistem gostujoˇcega raˇcunalnika, kar ga naredi izjemno lahkega in uˇcinkovitega. Kontejnerji se zaˇzenejo hitro in obratujejo lahkotno, torej je mogoˇce na sistemu poganjati veliko veˇc kontejnerjev kot virtualnih operacijskih sistemov. Kontejnerizacija torej reˇsuje oba problema: izolacijo in gostoto.
16
Teoretiˇcne osnove in pregled literature
2.2.3 Asinhrono programiranje
V naˇsem primeru se ukvarjamo s pretakanjem velike koliˇcine podatkov, saj ˇzelimo podatke zajemati s frekvenco vzorˇcenja do 192kHz in razmeroma visoko dinamiˇcno globino AD pretvorbe (16-bitno ali 24-bitno). Da lahko to doseˇzemo z uporabo pro- gramskega jezika Python, ki sam po sebi ni najhitrejˇsi, je potrebno uporabiti primerna orodja, ustrezne knjiˇzice in naˇcin programiranja. Poleg tega naˇsa aplikacija zahteva ˇse druge funkcionalnosti, kot so istoˇcasno izvajanje procesiranje signalov, prikazovanje podatkov veˇcim uporabnikom hkrati in upravljanje z enoto za zajemanje med tem, ko se meritve izvajajo. Na podlagi teh zahtev in omejitev smo se odloˇcili, da bomo precejˇsen del programa za zajemanje napisali na asinhron naˇcin.
V nadaljevanju bo v grobem predstavljeno asinhrono programiranje in kako se to razlikuje od bolj pogosto uporabljenega sinhronega programiranja. Velik del kode je napisane v programskem jeziku Python, za asinhrone operacije pa njegov vgrajeni modul Asyncio [29]. pri razumevanju tega ter njegove uporabe, smo si pomagali s knjigo avtorja C. Hattingh [30].
2.2.3.1 Primerjava sinhronega in asinhronega programiranja
Pri klasiˇcnemu programiranju se operacijska opravila izvajajo sinhrono oziroma eno za drugim. Z drugimi besedami, vedno moramo ˇcakati, da se trenutno opravilo zakljuˇci, da lahko zaˇcnemo z izvajanjem naslednjega. Za razliko od tega, se lahko pri asinhronemu programiranju premikamo na druga opravila ˇse preden se trenutno konˇca. Na ta naˇcin lahko operiramo z veˇc zahtevki hkrati in poslediˇcno opravimo veˇc opravil v precej krajˇsem ˇcasu. Za primerjavo izvajanja sinhronega in asinhronega programa ter laˇzjo predstavo si lahko ogledamo shemo 2.11. Ta shema sicer prikazuje idealen primer, ko so si vsa opravila neodvisna med seboj in se lahko izvajajo istoˇcasno. Vˇcasih je eno izmed opravil odvisno od drugega. V tem primeru se kombinira sinhroni in asinhroni naˇcin, kjer pa ˇse vedno v skupnem pridobimo na ˇcasu.
Glavni fokus asinhronega naˇcina programiranja je, kako ˇcimbolj uˇcinkovito istoˇcasno izvesti ˇcim veˇcje ˇstevilo opravil na eni niti. Tu moramo poudariti, da gre predvsem za vrsto opravil, pri katerih se med njihovo izvedbo pojavijo obdobja ˇcakanja in ki so med sebojneodvisna. Glavna logika je torej, da med tem ko ˇcakamo, da se doloˇceno opravilo izvrˇsi do konca (npr. ˇcakamo na odgovor), lahko nit izvaja drugo opravilo.
To pride ˇse posebno do izraza pri omreˇznem programiranju, saj so CPU-ji raˇcunalnika precej hitrejˇsi od hitrosti omreˇzja. CPU raˇcunalnika tako opravilo izvrˇsi hitro, vendar nato ˇcaka na I/O omreˇzja. Asinhroni naˇcin programiranja nam torej ponuja sledeˇca:
– Varno alternativo za programiranje prekinjevalne veˇcopravilnost (nitenje oz. ang.
threading) in s tem izognitvi hroˇsˇcem, tekmovalnim razmeram in drugim nepredvi- dljivim sluˇcajem, ki se pojavijo pri tovrstnem programiranju.
– Razmeroma enostaven naˇcin podpore veˇc tisoˇc istoˇcasnih povezav vtiˇcnic (ang. soc- ket connections). Z drugimi besedami, upravljanje z dlje ˇziveˇcimi povezavami za novejˇse tehnologije na podroˇcju IoT kot so WebSockets ali MQTT.
Vredno je ˇse omeniti, da en naˇcin programiranja sam po sebi ni nujno boljˇsi od dru- gega. Sta le drugaˇcna in vsak ima svoje prednosti in slabosti, ter jih uporabimo v
Teoretiˇcne osnove in pregled literature
Opravilo 1
Opravilo 1
Opravilo 2
Opravilo 2
Opravilo 3
Opravilo 3
Čas
Pridobljeni čas Sinhrono
Asinhrono
Slika 2.11: Primerjava poteka opravil pri sinhroni in asinhroni izvedbi.
razliˇcnih scenarijih, odvisno od zahtev naˇse aplikacije. Velikokrat se uporabljata tudi v kombinaciji, saj so doloˇcena opravila med seboj odvisna in jih ni mogoˇce vedno izvajati asinhrono.
Sočasnost
Paralelizem (Nitenje, Async IO)
(Multiprocesiranje)
Slika 2.12: Pozicioniranje asinhronega programiranja glede na druge podobne metode (nitenje in multiprocesiranje).
2.2.3.2 Osnovni gradniki Asyncio
Tu bomo po knjigi avtorja C. Hatting [30] opisali osnovne gradnike, ki so kljuˇcni pri asinhronem naˇcinu programiranja. Uradna Python dokumentacija za Asyncio [13] je v osnovi precej obseˇzna, vendar se moramo zavedati, da je veliko ˇstevilo API-jev v 18
Teoretiˇcne osnove in pregled literature modulu namenjenih razvijalcem spletnih ogrodji in knjiˇzic (kot je npr. Django, Flask itd.) torej jih povpreˇcen razvijalec za razvoj neke enostavne aplikacije ne potrebuje.
V nadaljevanju se bomo dotaknili glavnih podroˇcij, ki jih mora razvijalec poznati pri asinhronem programiranju v okviru programskega jezika Python.
Korutine (ang. corutines)
Korutina (ang. corutine) je objekt, ki je zmoˇzen nadaljevati izvedbo znotraj leˇzeˇce funkcije, ˇcetudi je bila ta zaustavljena pred dokonˇcanjem. Python je torej zmoˇzen
”preklapljati”med korutinami, medtem ko to med klasiˇcnimi funkcijami ni mogoˇce.
Zanka dogodka (ang. Event loop)
Zanka dogodkov je odgovorna za vse preklapljanje med korutinami, lovljenje izjem in ˇse veliko veˇc. Sama interakcija z zanko dogodkov pri programiranju z Asyncio modulom v programu ni vedno potrebna, je pa v specifiˇcnih primerih, ko potrebujemo veˇcji nadzor nad dogajanjem, nujna.
Naloge in prihodnosti (ang. Tasks and Futures)
Veˇcino ˇcasa se pri asinhronem programiranju uporabljajo naloge (ang. Tasks). Naloga nam predstavlja korutino, ki je v izvajanju. Obstajajo ˇse prihodnosti (ang. Futures), ki pa predstavljajo prihodnja konˇcana stanja aktivnosti (instanca dobi ob zaˇcetku izvajanja status ”ni ˇse dokonˇcno izvedena”, ampak vemo, da bo do enkrat v prihodnje
”konˇcana”).
Teoretiˇcne osnove in pregled literature
2.3 Procesiranje signalov
V nadaljevanju bodo predstavljene teoretiˇcne osnove metod, ki so bile uporabljene pri obdelavi dinamskih veliˇcin v naˇsi aplikaciji. Vse enaˇcbe, izpeljave in slike so povzete po knjigi avtorja K. Shin in sodelavcev [31].
2.3.1 Fourierjeve vrste
Z uporabo Fourierjeve vrste analiziramo poljubne periodiˇcne signale na naˇcin, da te opiˇsemo z vsoto sinusnih in kosinusnih funkcij, ki imajo ustrezno frekvenco, amplitudo in fazni zamik. Fourierjeva vrsta za periodiˇcni signalx(t) prikazan na sliki 2.13 je tako poenostavljeno opisana z enaˇcbo (2.1).
( ) x t
t TP
0
Slika 2.13: Periodiˇcni signal x(t) s periodo Tp.
x(t) =x(t+nTp) n=±1,±2,±3,... (2.1)
Ce ˇˇ zelimo tako periodiˇcno funkcijo opisati z vsoto sinusov in kosinusov, to prikazuje enaˇcba (2.2).
x(t) = a0
2 +
∞
∑︂
n=1
[︂
ancos
(︃2πnt Tp
)︃
+bnsin
(︃2πnt Tp
)︃]︂
(2.2)
Osnovna frekvenca signala znaˇsa f1 = 1/Tp in vse ostale frekvence so njeni veˇckratniki.
Srednja vrednost signalaa0/2 in koeficientaaninbn, v katerih so zapisani tudi podatki o amplitudi in faznem zamiku, so definirani z enaˇcbami:
a0 2 = 1
Tp
∫︂ Tp
0
x(t)dt (2.3)
an= 2 Tp
∫︂ Tp
0
x(t) cos
(︃2πnt Tp
)︃
dt n = 1,2,..., (2.4)
20
Teoretiˇcne osnove in pregled literature
bn = 2 Tp
∫︂ Tp
0
x(t) sin
(︃2πnt Tp
)︃
dt n= 1,2,..., (2.5)
Ce ˇˇ zelimo bolj eksplicitno pokazati podatke o amplitudi ter faznem zamiku periodiˇcnega signala pri frekvenci nf1, lahko enaˇcbo (2.2) zapiˇsemo na sledeˇc naˇcin:
x(t) = a0 2 +
∞
∑︂
n=1
Mncos(2πnf1t+ϕn), (2.6)
kjer je amplituda Mn=√︁
a2n+b2n in fazni zamik ϕn =arctan(︂
−abn
n
)︂
.
Fourierjevo vrsto lahko zapiˇsemo tudi v kompleksni obliki. Pri tem upoˇstevamo sledeˇco zvezo:
e±jω1nt = cos(ω1n t)±jsin(ω1n t), (2.7)
kjer veljaj =√
−1, terω1 = 2πT
p. ˇCe uvedemo ˇse, da velja c0 =a0/2, cn = (an−jbn)/2 inc∗n= (an+jbn)/2 lahko enaˇcbo (2.2) zapiˇsemo v obliki:
x(t) =c0+
∞
∑︂
n=1
cnej2πnt/Tp+
∞
∑︂
n=1
c∗n, ej2πnt/Tp (2.8)
kjer velja:
c0 = 1 Tp
∫︂ Tp
0
x(t)dt, (2.9)
cn = 1 Tp
∫︂ Tp
0
x(t)e−j2πnt/Tpdt, (2.10)
c∗n = 1 Tp
∫︂ Tp
0
x(t)ej2πnt/Tpdt =c−n, (2.11)
V (2.11) opazimo, da je uvedena negativna frekvenca c−n, ki v realnostni nima fizikal- nega pomena. V konˇcnem dobimo zapisa:
x(t) =c0+
∞
∑︂
n=−∞
cnej2πnt/Tp (2.12)
in
cn = 1 Tp
∫︂ Tp
0
x(t)e−j2πnt/Tpdt. (2.13)
Teoretiˇcne osnove in pregled literature
2.3.2 Spekter
V nadaljevanju bo predstavljena uvedba spektra procesa. Sklicujemo se na kompleksen zapis (2.12) in na (2.6), kjer upoˇstevamo le pozitivne frekvence. Slika 2.14 nam tako prikazuje amplitude |cn| v odvisnosti od frekvence f (ali ω), ki ga z drugimi besedami poimenujemo amplitudni spekter periodiˇcne funkcije x(t). ˇCe pa izriˇsemo fazni kot argcnv odvisnosti od frekvencef, dobimo tako imenovani fazni spekter, ki ga prikazuje slika 2.15. Kot je to razvidno s slike, to niso zvezne krivulje temveˇc le vrednosti ob diskretnih vrednostih za f =n/Tp,n = 0,±1,±2,...
f c
n1 TP
3 TP
1 TP
3 − TP
−
Slika 2.14: Amplitudni spekter Fourierjeve vrste.
arg c
nf
Slika 2.15: Fazni spekter Fourierjeve vrste.
Persevalov teorem - moˇcnostni spekter
Ce predpostavimo, da je signalˇ x(t) interpretiran kot napetost, je trenutna moˇc, ki je disipirana preko upora, katerega upornost znaˇsa 1Ω, enaka x2(t); povpreˇcna moˇc torej znaˇsa:
P = 1 TP
∫︂ TP
0
x2(t)dt. (2.14)
Ce upoˇstevamo enaˇˇ cbo (2.12) in princip ortogonalnosti, dobimo izraz, ki se imenuje Parsevalov teorem:
P = 1 TP
∫︂ TP
0
x2(t)dt =
∞
∑︂
n=−∞
|cn|2 (2.15)
22
Teoretiˇcne osnove in pregled literature Enaˇcba 2.15 v fizikalnem pomenu predstavlja, da lahko povpreˇcno moˇc signala x(t) dekompoziramo po frekvencah. Primer moˇcnostnega spektra nam prikazuje slika 2.16 iz katere je tudi razvidno, da ga predstavljajo le realne vrednosti, poleg tega pa se moramo zavedati, da ne nosi informacije o faznem zamiku.
f
2
c
n1 TP
3 TP
1 TP
3 − TP
−
Slika 2.16: Primer moˇcnostnega spektra.
2.3.3 Analogno digitalna pretvorba
Do tu smo si pogledali Fourierjevo transformacijo zveznega signala. Za izvedbo trans- formacije v realnih primerih ponavadi uporabimo raˇcunalnike. Zaradi tega je potrebno zapisati Fourierjevo vrsto v diskretni obliki, ki nam predstavlja dober pribliˇzek Fouri- erjevega integrala.
2.3.3.1 Vzorˇcenje signala
Fourierjevo transformacijo sekvence uvedemo s pomoˇcjo matematiˇcne ideje idealnega vzorˇcenja zveznega signala. Upoˇstevajoˇc ”vlaka”delta funkciji(t) =∑︁∞
n=−∞δ(t−n∆), ki so locirane vsakih ∆ sekund in jih spustimo preko zveznega signala x(t), lahko zapiˇsemo digitalni signal z diskretnimi vrednostmi matematiˇcno kot:
xs(t) =x(t) i(t) (2.16)
Obratno vrednost intervala zajemanja,fs= 1δ imenujemo frekveca vzorˇcenja. Vzorˇcenje zveznega signala prikazuje tudi slika 2.17.
s( ) x t
=
× ∆
... ...
i t( ) ( )t x
Slika 2.17: Ponazoritev vzorˇcenja signala.
Fourierjev transformacijski par po izpeljavi torej zapiˇsemo kot:
Teoretiˇcne osnove in pregled literature
X(ej2πf∆) =
∞
∑︂
n=−∞
x(n∆)e−j2πfn∆, (2.17)
X(n∆) = ∆
∫︂ 1/2∆
−1/2∆
X(ej2πf n∆)ej2πf n∆df (2.18)
2.3.3.2 Diskretna Fourierjeva transformacija
Kadar obravnavan signal ne traja neskonˇcno dolgo ˇcasa, je potrebno uporabiti dis- kretno Fourierjevo transformacijo, ki je, kot smo ˇze omenili, tudi osnova za izvajanje Fourierjeve transformacije pri digitalnem procesiranju signalov.
Pri izpeljavi izhajamo iz enaˇcbe (2.17), pri kateri spremenimo meje v vsoti za primer, ko imamo vrsto vrednosti x(n∆) in velja, da jen = 0,1, ..., N −1:
X(ej2πf∆) =
N−1
∑︂
n=0
x(n∆)e−j2πfn∆. (2.19)
Zanimajo nas vrednosti pri posameznih frekvencah f = k/N∆, kjer je k celo ˇstevilo.
Torej se izraz (2.19) preoblikuje v:
X(k) =
N−1
∑︂
n=0
x(n)e−j(2π/N)nk∆, (2.20)
ki predstavlja diskretno Fourierjevo transformacijo konˇcnega zaporedja z N elementi.
Inverzno obliko diskretne Fourierjeve transformacije predstavlja enaˇcba:
x(n) = 1 N
N−1
∑︂
n=0
X(k)ej(2π/N)nk. (2.21)
2.3.4 Oknjenje
Pri procesiranju signalov vedno gledamo ˇcasovno vrsto znotraj izbranega intervala. Kot to prikazuje slika 2.18, predpostavimo, da je ˇcasovna vrsta x(t) poznana na intervalu
−T /2≤t≤T /2.
24
Teoretiˇcne osnove in pregled literature
2 T 2
T
− t
w t ( ) ( )
x t 1.0
Slika 2.18: Oknjenje signala s pravokotnim oknom.
Signal opazujemo skozi pravokotno oknow(t), kjer velja:
w(t) = 1 |t|< T /2
= 0 |t|> T /2 (2.22)
in oknjen signal zapiˇsemo kot zmnoˇzek funkcij:
xT(n) =x(t) w(t). (2.23)
Ce ˇˇ zelimo na oknjenem signalu xT(t) izvesti Fourierjevo transformacijo, upoˇstevalo pravilo Fourierjeve transformacije produkta dveh signalov ter zapiˇsemo:
XT(f) =F(x(t) w(t)) =
∫︂ ∞
−∞
X(g)W(f−g)dg =X(f)∗W(f) (2.24) Fourierjeva transformacija produkta dveh funkcij je konvolucija njunih Fourierjevih transformacij. W(f) imenujemo spektralno okno in njegova oblika v primeru pravoko- tnega okna je vidna na sliki 2.19. Glavni reˇzenj (ang. main lobe) je posledica popaˇcitve, stranski reˇzenj (ang. side lobe) pa posledica frekvenˇcnega odtekanja.
1 T
2 T 1
−T 2
−T
Stranski reženj Glavni reženj
T
( ) W f
f
Slika 2.19: Fourierjeva transformacija okna w(t).
V praksi poleg pravokotnega okna najveˇckrat uporabljamo ˇse Bartlettovo (vidno na sliki 2.20), Hannovo (vidno na sliki 2.21) in Hammingovo (vidno na sliki 2.22) okno.
Teoretiˇcne osnove in pregled literature
T 2 T 2
−
w(t)
At
2T
4 T AT 2
W(f )
f
Slika 2.20: Bartlettovo okno v ˇcasovni in frekvenˇcni domeni.
w(t)
T AT 2 T 2
−
t
W(f )
2
f
T3 T AT 2
Slika 2.21: Hannovo okno v ˇcasovni in frekvenˇcni domeni.
W(f )
2
f
T3 T 0.54
w(t)
T 2 T 2
−
t
1.0
Slika 2.22: Hammingovo okno v ˇcasovni in frekvenˇcni domeni.
2.3.5 Spektralna gostota moˇ ci
Spektralna gostota moˇci (ang. Power spectral density) je funkcija, ki nam opisuje porazdelitev moˇci v odvisnosti od frekvenˇcnih komponent opazovanega signala. Pred- postavimo, da imamo oknjeni nakljuˇcni signal, ki je viden na sliki 2.23.
Gre za kratek zajem signala, torej lahko predpostavimo, da gre za impulzni signal, opiˇsemo ga kot Fourierjev integral:
x(t) =
∫︂ ∞
−∞
XT(f)ej2πf tdf. (2.25)
26
Teoretiˇcne osnove in pregled literature
2
−T
2
T t
( ) x t
T( ) x t
Slika 2.23: Primer oknjenega nakljuˇcnega signala
Ker se skupna energija signala, ko se T veˇca, pribliˇzuje neskonˇcnosti, zapiˇsemo pov- preˇcno moˇc signala kot:
1 T
∫︂ ∞
−∞
x2T(t)dt. (2.26)
Ce upoˇstevamo Parsevalov teorem dobimo:ˇ
1 T
∫︂ ∞
−∞
x2T(t)dt= 1 T
∫︂ T /2
−T /2
x2T(t)dt= 1 T
∫︂ ∞
−∞
|XT(f)|2df =
∫︂ ∞
−∞
1
T|XT(f)|2df,
(2.27) kjer je|XT(f)|2/T poimenovana vzorˇcna spektralna gostota moˇci in jo lahko zapiˇsemo:
Sˆ︁xx(f) = 1
T|XT(f)|2 (2.28)
Moˇc signala dolˇzine T je tako : 1
T
∫︂ ∞
−∞
x2T(t)dt =
∫︂ ∞
−∞
Sˆ︁xx(f)df. (2.29)
Ceˇ T → ∞enaˇcbo (2.27) zapiˇsemo:
Tlim→∞
1 T
∫︂ T /2
−T /2
x2T(t)dt =
∫︂ ∞
−∞
Tlim→∞
|XT(f)|2
T df. (2.30)
V primeru, da T → ∞, se izkaˇze, da Sˆ︁xx(f) v statistiˇcnem smislu ne konvergira. Tu torej govorimo o oceni vrednosti, ki jeSˆ︁xx(f) poslediˇcno neodvisna od dolˇzine signala: