Fixed all grammer mistakes
This commit is contained in:
parent
57998e3bc5
commit
3b5b544a3e
|
|
@ -9,10 +9,10 @@
|
|||
\chapter*{Kivonat}\addcontentsline{toc}{chapter}{Kivonat}
|
||||
|
||||
Adott egy tanszéken fejlesztett felhőalapú elosztott rendszer, melynek eszközei madárhangok azonosítására képesek.
|
||||
Ha a rendszer úgy észleli, hogy az egyik álatala vezérelt eszköz mikrofonja felvételén madárhang található,
|
||||
Ha a rendszer úgy észleli, hogy az egyik általa vezérelt eszköz mikrofonja felvételén madárhang található,
|
||||
akkor riasztást kezdeményez az eszközön ezzel elijesztve a madarat ezáltal megóvva a növényzetet.
|
||||
|
||||
A rendszernek több kisebb komponense van, amelyek rengeteg adatot dolgoznak fel és nincs jelenleg egy olyan egységes grafikus felület ahol a rendszer teljes állapotát
|
||||
A rendszernek több kisebb komponense van, amelyek rengeteg adatot dolgoznak fel és nincs jelenleg egy olyan egységes grafikus felület, ahol a rendszer teljes állapotát
|
||||
át lehetne tekinteni, ahol a feldolgozott adatokat vizualizálni lehetne.
|
||||
|
||||
A piacon létezik már több olyan szoftver csomag, amely hasonló problémákra próbál megoldást nyújtani, de ezek sem mindig
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ Ebben a fejezetben bemutatom a szerveroldal architektúráját, felépítését.
|
|||
%----------------------------------------------------------------------------
|
||||
\section{Architektúra}
|
||||
%----------------------------------------------------------------------------
|
||||
A szerveroldal fejlesztésénél a háromrétegú architektúrát alkalmaztam, melynek lényege, hogy az alkalmazást logikailag három elkülönülő részre bontjuk:
|
||||
A szerveroldal fejlesztésénél a három rétegú architektúrát alkalmaztam, melynek lényege, hogy az alkalmazást logikailag három elkülönülő részre bontjuk:
|
||||
\begin{itemize}
|
||||
\item \textbf{Adatelérési réteg}. Ez a rész felel a tárolt entitások modell definícióiért, illetve azoknak a kiolvasásáért, tárolásáért egy adatbázisból vagy fájlrendszerből.
|
||||
\item \textbf{Megjelenítési réteg}. Ezen réteg feladata a kliensoldal közvetlek kiszolgálása. Bármilyen irányú kommunikáció a kliensek felé ezen a rétegen keresztül történik.
|
||||
\item \textbf{Üzleti logikai réteg}. Minden ami nem a közvetlen kommunikációért, megjelenítésért vagy adat elérésért, tárolásért felel, az ide kerül.
|
||||
\item \textbf{Megjelenítési réteg}. Ezen réteg feladata a kliensoldal közvetlen kiszolgálása. Bármilyen irányú kommunikáció a kliensek felé ezen a rétegen keresztül történik.
|
||||
\item \textbf{Üzleti logikai réteg}. Minden, ami nem a közvetlen kommunikációért, megjelenítésért vagy adat elérésért, tárolásért felel, az ide kerül.
|
||||
A fenti két réteg között helyezkedik el és feladata a különböző folyamatok értékelése és futtatása, valamint az adatok feldolgozása.
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -79,15 +79,15 @@ melyeknek szintén van egy modellje \verb+Sensor+ néven. Ennek szintén van azo
|
|||
amely a hangüzenetek metaadatait reprezentálja. Többek között tartalmazza a kihelyezett eszköz egyedi azonosítóját és a hangüzenet keltének dátumát.
|
||||
|
||||
Ugyan itt található meg a \verb+User+ és \verb+Service+ entitások létrehozásáért, olvasásáért, szerkesztéséért és törléséért felelős szolgáltatások is.
|
||||
Valamint itt található még az autentikációért felelős szolgáltatás is. A felhasználók jelszavainak tárolására a HMAC (Hash-based Message Authentication Code) algorithmust,
|
||||
Valamint itt található még az autentikációért felelős szolgáltatás is. A felhasználók jelszavainak tárolására a HMAC (Hash-based Message Authentication Code) algoritmust,
|
||||
pontosabban annak a \verb+HMACSHA512+ \cite{hmacsha512} C\# implementációját használtam.
|
||||
|
||||
Minden jelszóhoz generálok egy egyedi kulcsot és azzal egy hash-t, majd ezeket tárolom a \verb+User+ modell \verb+PasswordSalt+ és \verb+PasswordHash+ mezőiben.
|
||||
Amikor egy felhasználó be akar jelentkezni először megvizsgálom, hogy egyáltalán létezik-e az adatbázisban az adott nevű felhasználó,
|
||||
ha igen, akkor a megadott jelszóból az imént említett folyamattal generált kulcsot és hash-t összehasonlítom az adatbázisban tárolttal.
|
||||
|
||||
Azért hasznos íly módon, és nem mondjuk egyszerű szöveges formában tárolni a felhasználók jelszavát, mert így a felhasználón kívül senki sem tudja, hogy mi volt az eredeti jelszava,
|
||||
az algorithmus egyirányú volta miatt\footnotemark. Ha véletlenül rossz kezekbe kerülne az adatbázis tartalma, akkor sem fognak tudni bejeletkezni a felhasználók adataival.
|
||||
Azért hasznos ily módon, és nem mondjuk egyszerű szöveges formában tárolni a felhasználók jelszavát, mert így a felhasználón kívül senki sem tudja, hogy mi volt az eredeti jelszava,
|
||||
az algoritmus egyirányú volta miatt\footnotemark. Ha véletlenül rossz kezekbe kerülne az adatbázis tartalma, akkor sem fognak tudni bejeletkezni a felhasználók adataival.
|
||||
|
||||
\footnotetext{Generálni egyszerű és gyors. Visszafejteni közel lehetetlen.}
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -100,10 +100,10 @@ frissüljön a felület.
|
|||
|
||||
Egy másik szerveroldalon használt szolgáltatás a Birbnetes MQTT kommunikációért felelős szolgáltatás,
|
||||
mely felregisztrál a \ref{subsect:birdnetes-ai-service}-as alfejezetben bemutatott AI Service által publikált üzenetekre.
|
||||
Ezekben az üzenetekben található a hanganyagok egyedi azonosítója, illetve azok seregélytől való származásának valószínüsége.
|
||||
Ezekben az üzenetekben található a hanganyagok egyedi azonosítója, illetve azok seregélytől való származásának valószínűsége.
|
||||
Ha a szolgáltatás kap egy ilyen üzenetet akkor lekérdezi a \ref{subsect:birdnetes-input-service}-es alfejezetben bemutatott Input Service-től
|
||||
a hanganyag azonosítójához tartozó metaadatokat.
|
||||
Ezekből felhasználva a kihelyezett eszköz azonosítóját, a hanganyag beérkezésének dátumát és az említett valószínüséget új üzenetek készülnek, melyeket egy pufferben tárolódnak.
|
||||
Ezekből felhasználva a kihelyezett eszköz azonosítóját, a hanganyag beérkezésének dátumát és az említett valószínűséget új üzenetek készülnek, melyeket egy pufferben tárolódnak.
|
||||
Ezt a folyamatot a \ref{fig:birdmap-mqtt-service}-es ábra szemlélteti.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
|
|
@ -114,7 +114,7 @@ Ezt a folyamatot a \ref{fig:birdmap-mqtt-service}-es ábra szemlélteti.
|
|||
\end{figure}
|
||||
|
||||
A puffer tartalmát másodperces gyakorisággal elküldöm a klienseknek a SignalR segítségével.
|
||||
Azért van szükség a puffer használatára, mert az MQTT-n érkezett üzenetek gyakorisága akár miliszekundum nagyságrendű is lehet.
|
||||
Azért van szükség a puffer használatára, mert az MQTT-n érkezett üzenetek gyakorisága akár milliszekundum nagyságrendű is lehet.
|
||||
Míg a szerver képes is az üzeneteket feldolgozni, ha ezeket rögtön tovább küldeném a kliensek felé, azok nem biztos, hogy képesek lennének rá.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -125,8 +125,8 @@ Itt történik a \ref{subsect:seeding} fejezetben leírt adatbázis seedelése i
|
|||
|
||||
Többek között a naplózás is itt kerül inicializálásra, mely az NLog saját konfigurációs fájljával történik.
|
||||
Meg lehet adni különböző szűrőket és kimeneteket, amellyel szelektálni lehet, hogy az egyes naplózott események hova kerüljenek.
|
||||
Például az MQTT szolgáltalás napló bejegyzéseit a \ref{lst:nlog-config} lista alapján szűrtem.
|
||||
Minden \verb+Debug+ szintől nagyobb és \verb+Error+ szinttől kisebb bejegyzés, mely tartalmazza az \verb+Mqtt+ kulcsszót az \verb+mqttFile+ azonosítójú fájlba kerül.
|
||||
Például az MQTT szolgáltatás napló bejegyzéseit a \ref{lst:nlog-config} lista alapján szűrtem.
|
||||
Minden \verb+Debug+ szinttől nagyobb és \verb+Error+ szinttől kisebb bejegyzés, mely tartalmazza az \verb+Mqtt+ kulcsszót az \verb+mqttFile+ azonosítójú fájlba kerül.
|
||||
|
||||
\begin{lstlisting}[style=xml, caption=Az NLog.config fájl egy részlete, label=lst:nlog-config]
|
||||
<targets>
|
||||
|
|
@ -184,14 +184,14 @@ A kontrollerek határozzák meg, hogy a szerveroldalon milyen végpontokat, mily
|
|||
}
|
||||
\end{lstlisting}
|
||||
|
||||
A jogosultságok kezelését a JSON Web Token-ekkel oldottam meg. A fejlasználó bejelentkezéskor kap egy ilyen token-t,
|
||||
A jogosultságok kezelését a JSON Web Token-ekkel oldottam meg. A felhasználó bejelentkezéskor kap egy ilyen token-t,
|
||||
amelyben tárolom a hozzá tartozó szerepet. A \ref{lst:devices-controller}-as listában látszik, hogy hogyan használom ezeket a szerepeket.
|
||||
A \verb+DevicesController+ végpontjait alapértelmezetten \verb+User+ és \verb+Admin+ jogosultságú felhasználó hívhatja, az "api/devices/online" végpontot azonban csak \verb+Admin+ jogosultságú.
|
||||
Hasonló képpen oldottam meg ezt a többi kontrollernél is. A \verb+User+ felhasználók csak olyan végpontokat hívhat, mely kizárolag az állapotok olvasásával jár.
|
||||
Hasonlóképpen oldottam meg ezt a többi kontrollernél is. A \verb+User+ felhasználók csak olyan végpontokat hívhat, mely kizárólag az állapotok olvasásával jár.
|
||||
Az \verb+Admin+ felhasználók hívhatnak bármilyen végpontot.
|
||||
|
||||
A szerveroldalon négy különböző kontroller található, melyek mindegyikének alapvető feladata az üzleti logikát megvalósító szolgáltatások használata, a működés naplózás,
|
||||
illetve az imént említett végpontok authorizálása és kiszolgálása. Ezeken kívül a kontrollerek speciális feladata a következő:
|
||||
illetve az imént említett végpontok autorizálása és kiszolgálása. Ezeken kívül a kontrollerek speciális feladata a következő:
|
||||
\begin{itemize}
|
||||
\item Az \textbf{AuthController} felel a felhasználók bejelentkezésének lebonyolításáért, a JSON Web Token elkészítéséért. Az \verb+[Authorize]+ helyett itt az \verb+[AllowAnonymous]+ attribútum van használva, mellyel azt lehet jelezni, hogy a végpont bejelentkezés nélkül is hívható.
|
||||
\item A \textbf{ServiceController} felel az alkalmazás által használt külső szolgáltatások állapotának lekérdezhetőségéért. Ilyenek például a Birbnetes rendszer vagy az MQTT szolgáltatás állapota.
|
||||
|
|
@ -200,7 +200,7 @@ illetve az imént említett végpontok authorizálása és kiszolgálása. Ezeke
|
|||
\end{itemize}
|
||||
|
||||
Az adatbázisból érkező adatok gyakran túl sok vagy túl kevés információt tartalmaznak ahhoz, hogy kiolvasás után rögtön elküldjem a kliensoldalnak.
|
||||
Például amikor a felhasználó bejelentkezik a kiolvasott \verb+User+ objektum tartalmazza annak jelszavát (hash-elt formában), viszont nem tartalmazza az authorizációhoz használt token adatait.
|
||||
Például amikor a felhasználó bejelentkezik a kiolvasott \verb+User+ objektum tartalmazza annak jelszavát (hash-elt formában), viszont nem tartalmazza az autorizációhoz használt token adatait.
|
||||
Ennek a megoldására adatátviteli objektumokat hoztam létre, melyek csak azokat a mezőket tartalmazzák amelyekre a felhasználónak szüksége van.
|
||||
Az adatbázisból kiolvasott objektum hasznos részeit és egyéb használni kívánt információt átmásolom az átviteli objektumba. Majd ezt küldöm el a kliensoldal felé.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Ebben a fejezetben bemutatom a kliensoldal architektúráját. Ismertetem a kül
|
|||
%----------------------------------------------------------------------------
|
||||
Az alkalmazásnak minden oldala egy külön React komponens, mely mindegyikének saját mappája van a főkönyvtár alatt,
|
||||
ahol az egyes oldalak által használt szolgáltatások és egyéb komponensek találhatóak.
|
||||
A közöses használt szolgáltatások és komponensek a common mappába kerültek.
|
||||
A közösen használt szolgáltatások és komponensek a common mappába kerültek.
|
||||
|
||||
A kliensoldal belépési pontja az \verb+App.js+ fájlban található \verb+App+ komponens.
|
||||
Itt egy React \verb+Switch+-ben fel van sorolva az összes oldal komponense azok elérési útvonalai szerint.
|
||||
|
|
@ -28,7 +28,7 @@ Az a komponens jelenik meg a felületen, amelyiknek \verb+path+ mező értéke m
|
|||
</Switch>
|
||||
\end{lstlisting}
|
||||
|
||||
Hozzáférés szempontjából három fajta oldalt különböztetünk meg:
|
||||
Hozzáférés szempontjából háromfajta oldalt különböztetünk meg:
|
||||
\begin{itemize}
|
||||
\item \textbf{Publikus oldal}. Az oldal bejelentkezés nélkül is látogatható.
|
||||
\item \textbf{Privát oldal}. Az oldal csak bejelentkezés után látogatható.
|
||||
|
|
@ -40,10 +40,10 @@ Paraméterében át lehet adni egy másik megjeleníteni kívánt komponenst, me
|
|||
Mivel minden komponens ebbe az bázis komponensbe van csomagolva, így akárhova navigálunk az oldalon a felület mindig egységes marad.
|
||||
|
||||
A másik komponens a \verb+PredicateRoute+, melynek paraméterében meg lehet adni egy feltételt, illetve egy másik komponenst.
|
||||
Ha a feltétel hamis akkor átírányítja a felhasználót a bejelentkező oldalra, ha igaz akkor megjeleníti a \verb+DefaultLayout+-ba csomagolt komponenst.
|
||||
Ha a feltétel hamis akkor átirányítja a felhasználót a bejelentkező oldalra, ha igaz akkor megjeleníti a \verb+DefaultLayout+-ba csomagolt komponenst.
|
||||
Publikus oldalnál a feltétel mindig igaz.
|
||||
Privátnál a feltétel a bejelentkezéshez van kötve.
|
||||
Az admin oldal feltétele egyrészt szintén a bejelentkezés, másrészt a felhasználó \verb+Admin+ jogolsultsága.
|
||||
Az admin oldal feltétele egyrészt szintén a bejelentkezés, másrészt a felhasználó \verb+Admin+ jogosultsága.
|
||||
Ezt a folyamatot próbálja szemléltetni a \ref{fig:birdmap-frontend-architecture}-es ábra.
|
||||
Legfelül sárgával vannak feltüntetve a hívható végpontok, alattuk a hozzájuk kapcsolt megjelenítendő komponensek, azok alatt pedig a hozzáférést szabályozó komponensek.
|
||||
|
||||
|
|
@ -59,13 +59,13 @@ Legfelül sárgával vannak feltüntetve a hívható végpontok, alattuk a hozz
|
|||
%----------------------------------------------------------------------------
|
||||
A szerveroldallal való kommunikációt rendkívül egyszerűen tudtam implementálni köszönhetően a \ref{subsect:backend-swagger}-as fejezetben bemutatott Swagger oldalnak
|
||||
és annak, hogy az NSwag Studio-val \cite{nswag-studio} a C\#-on kívül lehet TypeScript\footnotemark klienseket is generálni a leíró fájlból.
|
||||
Így készültek el a kommponensek kommunikációért felelős szolgáltatásai.
|
||||
Így készültek el a komponensek kommunikációért felelős szolgáltatásai.
|
||||
|
||||
\footnotetext{JavaScript-re épített statikus típusdefiníciókat tartalmazó nyelv. JavaScript és TypeScript együtt is használható.}
|
||||
%----------------------------------------------------------------------------
|
||||
\section{Komponensek}
|
||||
%----------------------------------------------------------------------------
|
||||
Ebben a szakaszban ismertete az egyes oldalak komponenseit és azok alkomponenseit,
|
||||
Ebben a szakaszban ismertetem az egyes oldalak komponenseit és azok alkomponenseit,
|
||||
illetve a navigációért felelős fejlécet.
|
||||
%----------------------------------------------------------------------------
|
||||
\subsection{Navigáció}
|
||||
|
|
@ -100,7 +100,7 @@ A generált szerverrel kommunikáló szolgáltatás be van csomagolva egy közö
|
|||
Ennek célja, hogy a bejelentkezés eredményét több komponens is olvashassa, hiszen az alkalmazás felületét alapvetően megkülönbözteti,
|
||||
egyrészt a bejelentkezés sikeressége, másrészt a bejelentkezett felhasználó jogosultsági köre.
|
||||
|
||||
Sikeres bejelentkezés után a szerver elküldi a felhasználó szerepét, illetve a hozzáférési token-t, amelyre a kliens többi szolgáltatásának is szüksége lesz a kommunkációhoz.
|
||||
Sikeres bejelentkezés után a szerver elküldi a felhasználó szerepét, illetve a hozzáférési token-t, amelyre a kliens többi szolgáltatásának is szüksége lesz a kommunikációhoz.
|
||||
Ezeket az oldal \verb+sessionStorage+-ában\footnotemark tárolom és a becsomagolt szolgáltatáson keresztül elérhetőek.
|
||||
|
||||
Kijelentkezni a navigációs fejlécben található profil ikonra való kattintással lehet.
|
||||
|
|
@ -190,7 +190,7 @@ Az állapotok változása esetén a \verb+DevicesContextProvider+-nek köszönhe
|
|||
%----------------------------------------------------------------------------
|
||||
Ezekkel a diagramokkal az a célom, hogy az eszközök által küldött észleléseket időrendben vizualizáljam.
|
||||
Megvalósításukhoz az Apexcharts Heatmap típusú diagramját használtam.
|
||||
A \ref{fig:dashboard-heatmap-second}-as ábrán látható diagram az elmúlt egy percben küldött, másodpercenként a legnagyobb, hangüzenetekből képzett valószínűségeket ábrozolja.
|
||||
A \ref{fig:dashboard-heatmap-second}-as ábrán látható diagram az elmúlt egy percben küldött, másodpercenként a legnagyobb, hangüzenetekből képzett valószínűségeket ábrázolja.
|
||||
A \ref{fig:dashboard-heatmap-minute}-es ábrán látható diagram pedig az elmúlt egy órában percenként a legnagyobbakat.
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
|
|
@ -226,12 +226,12 @@ Az egyes oszlopok három részre vannak bontva az üzenetek öt tized, hét tize
|
|||
%----------------------------------------------------------------------------
|
||||
\subsubsection{Üzenetek gyakorisága}
|
||||
%----------------------------------------------------------------------------
|
||||
Az oldalon található utolsó diagram egy vonal diagammn, melynek célja, hogy ábrázolja a rendszer által küldött üzenetek számát másodpercenként.
|
||||
Az oldalon található utolsó diagram egy vonal diagram, melynek célja, hogy ábrázolja a rendszer által küldött üzenetek számát másodpercenként.
|
||||
A \ref{fig:dashboard-messages-line}-es ábrán látható a komponens.
|
||||
A vízszintes tengelyen a legelső érték az alkalmazás által először észlelt üzenet időpontja.
|
||||
Az utolsó érték a legutoljára észlelt időpontja.
|
||||
A függőleges tengelyen az adott másodpercben érkező üzenetek száma van ábrázolva.
|
||||
Az előzőekkel ellentétben itt az adatok nincsennek szűrve a hangüzenet valószínűsége alapján,
|
||||
Az előzőkkel ellentétben itt az adatok nincsennek szűrve a hangüzenet valószínűsége alapján,
|
||||
tehát a rendszer által küldött összes üzenet látható.
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
|
|
@ -243,11 +243,11 @@ tehát a rendszer által küldött összes üzenet látható.
|
|||
%----------------------------------------------------------------------------
|
||||
\subsection{Devices}
|
||||
%----------------------------------------------------------------------------
|
||||
Ez az oldal lehetővé teszi a felhasználók számára az eszközök állapotának áttekintését, \verb+Admin+ felhasználók számára azok menedszelését is.
|
||||
Ez az oldal lehetővé teszi a felhasználók számára az eszközök állapotának áttekintését, \verb+Admin+ felhasználók számára azok menedzselését is.
|
||||
Az eszközök dinamikusan jelennek meg a \verb+DevicesContextProvider+ adatai alapján, melyek megjelenítésére a Material UI \verb+Accrordion+ komponensét használom.
|
||||
Ennek fejlécében az eszköz neve, egyedi azonosítója és státusza található. A lenyíló részben pedig az eszköz által használt szenzorok neve, azonosítója és státusza.
|
||||
\verb+Admin+ felhasználók számára a felület két fajta gombbal bővül, mellyekkel be és ki lehet kapcsolni az egyes eszközöket, szenzorokat.
|
||||
Az \verb+Accordion+-ok felett található egy külön panel, mellyel egyszerre lehet kezelni az összes eszközt és azok szenzorait.
|
||||
\verb+Admin+ felhasználók számára a felület két fajta gombbal bővül, melyekkel be és ki lehet kapcsolni az egyes eszközöket, szenzorokat.
|
||||
Az \verb+Accordion+-ok felett található egy külön panel, mellyel egyszerre lehet kezelni az összes eszközt és azok szenzorjait.
|
||||
A Devices oldal felülete a \ref{fig:frontend-devices}-es ábrán,
|
||||
az \verb+Admin+ felhasználók számára nyújtott plusz funkciók a \ref{fig:frontend-devices-admin}-as ábrán láthatók.
|
||||
\begin{figure}[!ht]
|
||||
|
|
@ -272,14 +272,14 @@ Ezt használva megjelenítem a rendszer összes eszközét azok koordinátái sz
|
|||
A kék színű ikonok jelölik a bekapcsolt állapotban lévő, a sárga a kikapcsolt állapotban lévő,
|
||||
a piros pedig a hibás állapotban lévő eszközöket.
|
||||
Ha a felhasználó az egerét az ikonok fölé helyezi, megjelenik egy szövegdoboz, melyben az eszköz azonosítója és státusza látható.
|
||||
Az ikonra kattinta a felhasználó a Devices oldalra kerül, ahol megnyílik a kattintott eszköz \verb+Accordion+-ja.
|
||||
Az ikonra kattintva a felhasználó a Devices oldalra kerül, ahol megnyílik a kattintott eszköz \verb+Accordion+-ja.
|
||||
|
||||
A \verb+DevicesContext+ tartalmazza az eszközök által küldött üzenetek adatait,
|
||||
melyeknek a 0.5 valószínűségtől nagyobb részhalmazát a hőtérkép által kezelhető adatokká konvertálok.
|
||||
Egyrészt szükség van az előbb is említett földrajzi koordinátákra, melyeket az üzenetek eszköz azonosítója alapján határozok meg.
|
||||
Másrészt szükség van egy súly értékre, mely a pont színezésének pirosságát határozza meg.
|
||||
Ezt az értéket az üzenetek valószínűség értékével tettem egyenlővé.
|
||||
Minnél több magasabb valószínűségű riasztás érkezik egy adott eszköztől, a körülötte lévő terület annál pirosabb lesz.
|
||||
Minél több magasabb valószínűségű riasztás érkezik egy adott eszköztől, a körülötte lévő terület annál pirosabb lesz.
|
||||
|
||||
A \ref{fig:frontend-heatmap}-ös ábra mutatja a térkép működését miközben 4 eszköz is seregélyeket észelt.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ A jellemző adatvizualizációs megoldások közül az alábbi hármat találtam
|
|||
\begin{itemize}
|
||||
\item \textbf{Hőtérkép}. Hasznos lenne egy olyan felület, ahol az eszközök GPS koordinátái és a seregély detektálást jelző üzenetek alapján, meg lehetne jeleníteni a seregélyek hozzávetőleges előfordulásának helyeit és gyakoriságát egy térképen, hőtérképes formában.
|
||||
\item \textbf{Eszközállapotok}. Jelenleg a Command and Control mikroszolgáltatás felé indított kéréseken kívül, nincs lehetőség a kihelyezett eszközök állapotának vizsgálatára. Szükség lenne egy olyan felületre, ahol ezek állapotai láthatóak, esetleg dinamikusan is frissülnek.
|
||||
\item \textbf{Diagramok}. A hőtérképen kívül egyéb olyan diagramok is hasznosak lehetnek, ahol látható például, hogy melyik eszköz melyik percben észlelt madárhangot vagy, hogy egy eszköz összesen hány madárhangot észelt. Minnél több információ, annál jobb.
|
||||
\item \textbf{Diagramok}. A hőtérképen kívül egyéb olyan diagramok is hasznosak lehetnek, ahol látható például, hogy melyik eszköz melyik percben észlelt madárhangot vagy, hogy egy eszköz összesen hány madárhangot észlelt. Minél több információ, annál jobb.
|
||||
\end{itemize}
|
||||
Ezeken kívül fontos követelmény volt még, hogy az alkalmazásom futtatható legyen Linux környezetben is, hogy az telepíthető legyen a Birbnetes Kubernetes \cite{kubernetes} klaszterébe.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Az éles rendszerrel való kommunikáció megvalósításához készítenem kell
|
|||
Ehhez először készítettem egy Dockerfile-t \cite{dockerfile}, mely az image-ek automatikus elkészítését teszi lehetővé.
|
||||
Utasításokat lehet benne felsorolni, melyekkel a konténer környezetét kell felépíteni.
|
||||
Meg lehet adni kiindulópontokat, mely az image alapjául szolgál.
|
||||
Erre a célra én az ASP.NET futtatokörnyeztét használtam, mely tartalmazza az alkalmazás futtatásához szükséges parancsokat.
|
||||
Erre a célra én az ASP.NET futtatókörnyeztét használtam, mely tartalmazza az alkalmazás futtatásához szükséges parancsokat.
|
||||
Ezek után a Dockerfile utasításait használva bemásolom a \verb+Release+ konfigurációval fordított alkalmazásomat a konténer egy mappájába,
|
||||
majd a belépési pont utasítással megadom az alkalmazás indításához szükséges parancsot.
|
||||
Ezt futtatva sikeresen elkészül a Docker image.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ A Visual Studio \cite{vs} a Microsoft fejlesztőkörnyezete. Jól alkalmazható
|
|||
%----------------------------------------------------------------------------
|
||||
\subsection{Visual Studio Code}
|
||||
%----------------------------------------------------------------------------
|
||||
Egy másik Microsoft termék, viszont a fentivel ellentétben a Visual Studio Code \cite{vs-code} inkább szövegszerkeztő, mint fejlesztőkörnyezet.
|
||||
Egy másik Microsoft termék, viszont a fentivel ellentétben a Visual Studio Code \cite{vs-code} inkább szövegszerkesztő, mint fejlesztőkörnyezet.
|
||||
Ennek köszönhetően jelentősen gyorsabb és egyszerűbb a használata. Különféle bővítmények használatával nagyon jó program nyelv támogatottságot lehet elérni.
|
||||
Többek között ezen okok miatt preferáltam a kliensoldal fejlesztésére.
|
||||
|
||||
|
|
@ -53,20 +53,20 @@ amivel már foglalkoztam korábban, amivel gyorsabban és rutinosabban megy a fe
|
|||
Másrészt nemrég jelent meg a .NET új 5-ös verziója, melynek használatával jelentős teljesítmény javulást ígértek több területen is, és úgy gondoltam, hogy ez a projekt tökéletes lenne
|
||||
ennek próbatételére.
|
||||
|
||||
Mindemellett a .NET teljesen platformüggetlen, mely az egyik legfontosabb követelmény volt az alkalmazással szemben.
|
||||
Mindemellett a .NET teljesen platformfüggetlen, mely az egyik legfontosabb követelmény volt az alkalmazással szemben.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\subsection{ASP.NET Core}
|
||||
%----------------------------------------------------------------------------
|
||||
Az ASP.NET Core a .NET család ingyenes, nyílt forráskódú webes keretrendszere. Gyors és moduláris fejlesztést tesz lehetővé,
|
||||
mely főként a csomagkezelő rendszerének, a NuGet-nek \cite{nuget} köszönhető.
|
||||
Használatána egyik előnye, hogy ugyan az a C\# kód tud futni a szerver éa a kliens oldalon, de támogat más kliens oldali keretrendszereket is, mint például az Angular-t, a Vue.js-t
|
||||
Használatának egyik előnye, hogy ugyan az a C\# kód tud futni a szerver és a kliens oldalon, de támogat más kliens oldali keretrendszereket is, mint például az Angular-t, a Vue.js-t
|
||||
vagy a React.js-t.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\subsection{Entity Framework Core}
|
||||
%----------------------------------------------------------------------------
|
||||
Az Entity Framework Core (röviden EF Core) egy objektum-relációs leképező keretrendszer a .NET-hez. Az adatbázissal való kommunikációt könnyítését szolgálja.
|
||||
Az Entity Framework Core (röviden EF Core) egy objektum-relációs leképző keretrendszer a .NET-hez. Az adatbázissal való kommunikációt könnyítését szolgálja.
|
||||
Használatával C\#-ban lehet adatbázis lekérdezéseket írni a LINQ (Language-Integrated Query) szoftvercsomag segítségével.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -117,7 +117,7 @@ Használatának egyik előnye, hogy automatizált az állapot kezelés, tehát h
|
|||
A Material \cite{material} elsősorban egy kezelőfelület tervezési útmutató a Google által, melyet követve szép és minőségi felületeket lehet készíteni.
|
||||
|
||||
A Material UI \cite{material-ui} egy szoftvercsomag, mely ezeket az útmutatásokat követő egyszerű React komponenseket tartalmaz.
|
||||
Alkalmazásával könnyő esztétikus felhasználói felületeket készíteni, minimalizált a CSS használattal.
|
||||
Alkalmazásával könnyű esztétikus felhasználói felületeket készíteni, minimalizált a CSS használattal.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\subsection{Apexcharts}
|
||||
|
|
@ -132,5 +132,5 @@ A Google szinte összes termékének van API-ja, ami lehetővé teszi a programo
|
|||
A Google Maps sincs másképp és mivel ennek interfésze külön támogatja a hőtérképes réteg használatát is, nem gondoltam, hogy ettől jobb eszközt tudnék találni a feladat megvalósítására.
|
||||
|
||||
A Google Maps API-t, ami alapvetően csak egy JavaScript csomag, rengetegen újracsomagolják, hogy különböző részét, különböző keretrendszerekben is lehessen használni.
|
||||
Ezek közül én a Google Map React \cite{google-map-react}-et választottam, egyrészt mert támogatja a hőtérképes réteg használatát,
|
||||
Ezek közül én a Google Map React-et \cite{google-map-react} választottam, egyrészt mert támogatja a hőtérképes réteg használatát,
|
||||
másrészt mert lehetővé teszi a térképen való React komponensek renderelését az alapértelmezett markerek helyett.
|
||||
|
|
@ -14,16 +14,16 @@ melyeket az alábbi szekciókban ismertetek.
|
|||
\section{Helyettesítő szolgáltatások}
|
||||
%----------------------------------------------------------------------------
|
||||
Az alkalmazásom szerver oldali szolgáltatásai a Birbnetes Command and Control (a kódban Device) és Input Service-ekkel azok OpenAPI leíróiból generált interfészein keresztül kommunikál.
|
||||
Ezen intefészek mögé bármilyen implementáció regisztrálható, mely helyettesíti az éles rendszer működését.
|
||||
Ezen interfészek mögé bármilyen implementáció regisztrálható, mely helyettesíti az éles rendszer működését.
|
||||
|
||||
Készítettem egy osztályt \verb+DummyDeviceAndInputService+ néven, mely a szerver indulásakor mű eszközadatokat generál egy lokális változóval állítható darabszámban,
|
||||
Készítettem egy osztályt \verb+DummyDeviceAndInputService+ néven, mely a szerver indulásakor mű eszköz adatokat generál egy lokális változóval állítható darabszámban,
|
||||
majd ezeket egy belső listában tárolja. Az eszközök státuszát és koordinátáit egy véletlenszám generátor segítségével határozom meg.
|
||||
Az osztály implementálja a Device Service interfészét, melynek metódusai az imént említett mű eszközlista elemeivel dolgoznak,
|
||||
azok státuszát olvassák és módosítják.
|
||||
Illetve implementálja az Input Service interfészét,
|
||||
melynek metódusa bármilyen paraméterből kapott egyedi azonosító esetén visszaad egy véletlenszerűen kiválasztott bekapcsolt státuszú eszközt a listából.
|
||||
|
||||
Az alkalmazás által regisztrált és ezáltal használt intefész implementációi a konfigurációs fájl egy logikai értéke alapján cserélhető az éles és a helyettesítő között,
|
||||
Az alkalmazás által regisztrált és ezáltal használt interfész implementációi a konfigurációs fájl egy logikai értéke alapján cserélhető az éles és a helyettesítő között,
|
||||
a \ref{lst:dummy-service-registration}-es listában látható módon.
|
||||
\newpage
|
||||
\begin{lstlisting}[style=csharp, caption=A helyettesítő és az éles szolgáltatások regisztrálásának logikája, label=lst:dummy-service-registration]
|
||||
|
|
@ -50,7 +50,7 @@ Indítható vele MQTT szerver, feliratkozó kliens és publikáló kliens is.
|
|||
Ezek meglétével az alkalmazás képes az üzenetek manuális publikálására egy a felületen beállítható témában.
|
||||
Én azonban szerettem volna az üzeneteket automatikusan bizonyos időközönként küldeni,
|
||||
ezért átalakítottam az alkalmazást az igényeimnek megfelelően a \ref{fig:mqtt-tester}-es ábrán látható módon.
|
||||
Elhelyeztem a fejlületen egy csúszkát, mellyel az üzenet küldés intervalluma állítható, illetve két új gombot,
|
||||
Elhelyeztem a felületen egy csúszkát, mellyel az üzenet küldés intervalluma állítható, illetve két új gombot,
|
||||
melyekkel az üzenet küldő időzítő indítható és megállítható.
|
||||
Az alkalmazás képes üzenetek adatainak generálására, mellyel az AI Service által publikált üzenetek modelljeivel azonos adatokat generálok.
|
||||
\begin{figure}[!ht]
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ Ez több okból is hasznos:
|
|||
A mikroszolgáltatások (microservices) nem sok mindenben különböznek egy általános szolgáltatástól.
|
||||
Ugyan úgy valamilyen kéréseket kiszolgáló egységek, legyen az web kérések kiszolgálása HTTP-n keresztül
|
||||
vagy akár parancssori utasítások feldolgozása. Az egyetlen fő különbség az a szolgáltatások felelősségköre.
|
||||
A mikroszolgáltatások fejlesztésénél a fejlesztők elsősorban arra törekednek, hogy egy komponensnek minnél kevesebb feladata és függősége legyen,
|
||||
ezzel megnő a tesztelhetőség és könyebb a skálázhatóság.
|
||||
A mikroszolgáltatások fejlesztésénél a fejlesztők elsősorban arra törekednek, hogy egy komponensnek minél kevesebb feladata és függősége legyen,
|
||||
ezzel megnő a tesztelhetőség és könnyebb a skálázhatóság.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\subsubsection{Konténerek}
|
||||
|
|
@ -52,7 +52,7 @@ Kihasználja és ötvözi az imént említett technológiák előnyeit, hogy egy
|
|||
Használatával felgyorsulhat és automatizált lehet az egyes konténerek telepítése, futtatása, de talán a legfőbb előnye,
|
||||
hogy segítségével könnyedén megoldható a rendszert ért terhelési igények szerinti dinamikus skálázódás.
|
||||
Azok a mikroszolgáltatások, amikre a rendszernek épp nincs szüksége, minimális erőforrást igényelnek a szerveren,
|
||||
így nem kell utánnuk annyit fizetni sem. Ezzel ellentétben, ha valamely szolgáltatás után hirtelen megnő az igény,
|
||||
így nem kell utánuk annyit fizetni sem. Ezzel ellentétben, ha valamely szolgáltatás után hirtelen megnő az igény,
|
||||
akkor az könnyedén duplikálható.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -61,14 +61,14 @@ akkor az könnyedén duplikálható.
|
|||
%----------------------------------------------------------------------------
|
||||
Az MQTT (Message Queue Telemetry Transport) az egy kliens-szerver publish/subscribe üzenetküldő protokoll. Könnyű implementálni és alacsony a sávszélesség igénye,
|
||||
mellyel tökéletes jelöltje a Machine to Machine (M2M), illetve az Internet of Things (IoT) kommunikáció megvalósítására.
|
||||
Működéséhez szükség van egy szerverre, amelynek feladata a beérkező üzenetek továbbküldése témák alapján. Egyes kliensek fel tudnak iratkozni bizonyos témákra, míg más kliensek publikálnak
|
||||
Működéséhez szükség van egy szerverre, amelynek feladata a beérkező üzenetek tovább küldése témák alapján. Egyes kliensek fel tudnak iratkozni bizonyos témákra, míg más kliensek publikálnak
|
||||
és a szerver levezényli a két fél között a kommunikációt.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\subsection{OpenAPI}
|
||||
%----------------------------------------------------------------------------
|
||||
Az OpenAPI egy nyilvános alkalmazás-programozási leíró, amely a fejlesztők számára hozzáférést biztosít egy másik alkalmazáshoz.
|
||||
Az API-k lírják és meghatározzák, hogy egy alkalmazás hogyan kommunikálhat egy másikkal,
|
||||
Az API-k leírják és meghatározzák, hogy egy alkalmazás hogyan kommunikálhat egy másikkal,
|
||||
melyet használva a fejlesztők könnyedén képesek a kommunikációra képes kódot írni vagy generálni.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -109,7 +109,7 @@ Tartalmaznak még egy hangszórót is, mely a madarak elijesztését szolgálja.
|
|||
A kihelyezett IoT eszközök által felvett hangfájlok ezen a komponensen keresztül érkeznek be a rendszerbe.
|
||||
Itt történik a hanganyaghoz tartozó metaadatok lementése az Input Service saját relációs adatbázisába.
|
||||
Ilyenek például a beküldő eszköz azonosítója, a beérkezés dátuma vagy a hangüzenet rendszerszintű egyedi azonosítója.
|
||||
Amint a szolgáltatás a berékezett üzenettel kapcsolatban elvégezte az összes feladatát,
|
||||
Amint a szolgáltatás a beérkezett üzenettel kapcsolatban elvégezte az összes feladatát,
|
||||
publikál egy üzenetet egy másik üzenetsorra a többi kliensnek feldolgozásra.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -130,6 +130,6 @@ Ha igen, akkor az üzenetsoron küld egy riasztás parancsot a hanganyagot küld
|
|||
%----------------------------------------------------------------------------
|
||||
\subsubsection{Command and Control Service}
|
||||
%----------------------------------------------------------------------------
|
||||
A Command and Control Service az előzőekkel ellentétben egyáltalán nem vesz részt a minták fogadásában, feldolgozásában vagy kezelésében.
|
||||
Felelősége az eszközök és azok szenzorai állapotának menedzselése és követése.
|
||||
A Command and Control Service az előzőkkel ellentétben egyáltalán nem vesz részt a minták fogadásában, feldolgozásában vagy kezelésében.
|
||||
Felelősége az eszközök és azok szenzorjai állapotának menedzselése és követése.
|
||||
Ezen keresztül lehet az egyes eszközöket ki- és bekapcsolni.
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
%----------------------------------------------------------------------------
|
||||
Szőlőtulajdonosoknak éves szinten jelentős kárt okoznak a seregélyek, akik előszeretettel választják táplálékul a megtermelt szőlőt.
|
||||
Erre a problémára dolgoztak ki a tanszéken diáktársaim egy felhőalapú konténerizált rendszert, a Birbnetes-t
|
||||
mely a természetben elkelyezett eszközökkel kommunikál, azokat vezérli.
|
||||
mely a természetben elhelyezett eszközökkel kommunikál, azokat vezérli.
|
||||
Az eszközök bizonyos időközönként hangfelvételt készítenek a környezetükről,
|
||||
majd valamilyen formában elküldik ezeket a felvételeket a központi rendszernek,
|
||||
amely egy erre a célra kifejlesztett mesterséges intelligenciát használva eldönti
|
||||
|
|
@ -15,17 +15,17 @@ berendezését, hogy elijessze a madarakat.
|
|||
\section{Probléma}
|
||||
%----------------------------------------------------------------------------
|
||||
A jelen rendszer használata során nincs vizuális visszacsatolás az esetleges riasztásokról azok gyakoriságáról
|
||||
és a rendszer állapotáról sem. Különböző diagnosztikai eszközök ugyan implementálva lettek mint például
|
||||
és a rendszer állapotáról sem. Különböző diagnosztikai eszközök ugyan implementálva lettek, mint például
|
||||
a naplózás vagy a hiba bejelentés, de ezek használata nehézkes, nem kézenfekvő.
|
||||
Szükség van egy olyan megoldásra amivel egy helyen és egyszerűen lehet kezelni és felügyelni a rendszer egyes elemeit.
|
||||
Szükség van egy olyan megoldásra, amivel egy helyen és egyszerűen lehet kezelni és felügyelni a rendszer egyes elemeit.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
\section{Megoldás}
|
||||
%----------------------------------------------------------------------------
|
||||
A jelen szakdolgozat egy olyan webes alkalmazás elkészítését dokumentálja, melyel a felhasználók képesek
|
||||
A jelen szakdolgozat egy olyan webes alkalmazás elkészítését dokumentálja, mellyel a felhasználók képesek
|
||||
a természetben elhelyezett eszközök állapotát vizsgálni, azokat akár ki és bekapcsolni igény szerint.
|
||||
Az egyes rendszer eseményeket vizsgálva a szoftver statisztikákat készít, melyeket különböző diagramokon ábrázolok.
|
||||
Ilyen statisztikák például, hogy időben melyik eszköz mikor észlelt madár hangot, vagy hogy hány hang üzenet érkezik
|
||||
Ilyen statisztikák például, hogy időben melyik eszköz mikor észlelt madárhangot, vagy hogy hány hang üzenet érkezik
|
||||
az eszközöktől másodpercenként.
|
||||
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
@ -33,7 +33,8 @@ az eszközöktől másodpercenként.
|
|||
%----------------------------------------------------------------------------
|
||||
A szakdolgozatom első részében, a \ref{chapt:birdnetes-introduction}. fejezetben, bemutatom a vizualizálni kívánt rendszer felépítését, az egyes komponensek közötti kapcsolatokat,
|
||||
valamint a vizualizációs szempontból releváns technológiákat, amire a rendszer épült.
|
||||
A 3. fejezetben ismertetem a jelenleg az iparban is használt mikroszolgáltatás működését vizualizáló alternatívákat, majd a saját megoldásom tervezetét, az arra vonatkozó elvárásokat.
|
||||
A 4. fejezetben az alkalmazásom által használt technológiákat mutatom be, ezzel előkészítve az 5. és 6. fejezetet, ahol ismertetem a szerver- és kliensalkalmazások felépítését.
|
||||
A 7. és 8. fejezet az alkalmazás teszteléséről és telepítéséről szól.
|
||||
A \ref{chapt:birdmap-introduction} fejezetben ismertetem a jelenleg az iparban is használt mikroszolgáltatás működését vizualizáló alternatívákat, majd a saját megoldásom tervezetét, az arra vonatkozó elvárásokat.
|
||||
A \ref{chapt:birdmap-technologies} fejezetben az alkalmazásom által használt technológiákat mutatom be,
|
||||
ezzel előkészítve az \ref{chapt:birdmap-backend} és \ref{chapt:birdmap-frontend} fejezetet, ahol ismertetem a szerver- és kliensalkalmazások felépítését.
|
||||
A \ref{chapt:birdmap-test} és \ref{chapt:birdnetes-kubernetes} fejezet az alkalmazás teszteléséről és telepítéséről szól.
|
||||
Az utolsó fejezetben értékelem a munkám eredményét, levonom a tapasztalatokat és bemutatok néhány továbbfejlesztési lehetőséget.
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
Úgy gondolom, hogy az alkalmazásom elérte a célját.
|
||||
Egy használható felületet nyújt a Birbnetes mikroszolgáltatás rendszere működésének vizualizálására.
|
||||
A fejlesztés közben jelentős figyelmet fordítottam arra, hogy az alkalmazás felületi és kód komponensei között is
|
||||
minimalizáltak legyenek a függőségek, így a rendszerben történő változások esetén azok könnyen cseréhetőek, bővíthetőek.
|
||||
minimalizáltak legyenek a függőségek, így a rendszerben történő változások esetén azok könnyen cserélhetőek, bővíthetőek.
|
||||
%----------------------------------------------------------------------------
|
||||
\section{Továbbfejlesztési lehetőségek}
|
||||
%----------------------------------------------------------------------------
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue