2021-05-22 20:04:13 +02:00
parent 30b93340e1
commit 230d60bf19
7 changed files with 40 additions and 121 deletions
							
							
								
							
							
						
@@ -8,13 +8,13 @@
A kártevő madarak hangalapú azonosítására dolgozott ki egy mesterséges intelligenciát alkalmazó megoldást diplomamunkája során Nagy Kristóf. Az ő munkájára alapoztunk ezt követően egy éves projekt munkát Torma Kristóffal jelen diplomamunkát megelőző évben, így itt csak rövid áttekintést szeretnék adni róla.
Ez a projekt alkalmas arra, hogy jól szemléltesse a peremhálózaton történő adat aggregációs képességeket a \gls{felho} szoftver számára. A projekt jól szemlélteti egy ilyen architektúra átültetésének kihívásait perem és \gls{felho} számítástechnikai rendszerre.
Ez a projekt alkalmas arra, hogy jól szemléltesse a peremhálózaton történő adat aggregációs képességeket a felhő szoftver számára. A projekt jól szemlélteti egy ilyen architektúra átültetésének kihívásait perem és felhő számítástechnikai rendszerre.
\section{Előzetes munka}
A Nagy Kristóf által megalkotott detekciós algoritmus felhasználást olyan megoldásban láttuk, ahol termőföldekre kihelyezett, nagy mennyiségben telepített \acrfull{iot} eszközök gyűjtik a hangmintákat és továbbítják a központi feldolgozó egység felé, amely a hangminták intelligens felismerését végzi. A kártékony madarak hangjának azonosítása után pedig valamilyen beavatkozást tudnak tenni a madarak elriasztásának érdekében (Például: a természetes ellenségeinek hangját lejátszani)
A rendszert amelyet fejlesztettünk hagyományos \gls{felho} architektúrára terveztük. Az \acrshort{iot} eszközök közvetlenül a \gls{felho}ben futó szolgáltatásokkal kommunikálnak.
A rendszert amelyet fejlesztettünk hagyományos felhő architektúrára terveztük. Az \acrshort{iot} eszközök közvetlenül a felhőben futó szolgáltatásokkal kommunikálnak.
\subsection{Intelligens felismerés}
							
							
							
								
							
						
@@ -24,7 +24,7 @@ A hangminták felismerése egy két szintű \acrfull{mi} rendszerben történik.
A második szinten egy sokkal bonyolultabb \acrfull{cnn} alapú algoritmus áll. A \acrshort{cnn} által használt modell úgy lett tanítva, hogy a rögzített -- feltehetően -- madárhangokat tudja osztályokba sorolni. Így képes specifikusan a seregély hangját felismerni és elkülöníteni a többi madárhangtól.
A korábban említett \acrshort{svm} alapú komponens alacsony erőforrás igénye miatt miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a \gls{felho} által nyújtott komolyabb számítási teljesítményt. 
A korábban említett \acrshort{svm} alapú komponens alacsony erőforrás igénye miatt miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a felhő által nyújtott komolyabb számítási teljesítményt. 
Az algoritmusok elméleti működéséről a következő fejezetek adnak áttekintést.
							
								
							
							
								
							
							
						
@@ -91,7 +91,7 @@ Az erre telepített szoftver komponens két részre bontható. Platform függő
A \textbf{platform-illesztő} feladata az, hogy absztrakciós rétegként szolgáljon a platform specifikus hardver vezérlési és illesztési logika fölé, ezzel egy egységes programozói interfészt biztosítva az üzleti logika számára. Ennek az az előnye, hogy a fejlesztésnél használt konkrét hardver könnyen cserélhető, sőt akár az üzleti logika módosítás nélkül áthelyezhető egy kész termékbe is. Minden alkalommal ha változik a hardver csak a platformillesztő komponenst kell módosítani. Ebből a komponensből akár többet is fenntarthatunk, így egyszerre több különböző platformot tesztelhetjük az üzleti logikát annak bármilyen módosítása nélkül.
Az \textbf{üzleti logika} lényegében minden egyéb, ami nem platform specifikus. Felépítése egy három fázisú csővezeték. Az első fázisban a platform illesztőn keresztül megkap egy szenzor adatot. Ez lehet egy hangfájl a mikrofonról de bármilyen más szenzortól származó mérési érték is. Ezután egy előfeldolgozó lépés következik, amely képes döntést hozni arról, hogy az adott mérést továbbítsa-e a következő fázisra, amely egy ideális protokollon elküldi a hangmintát a \gls{felho}be. A folyamat egy időzítő által meghatározott intervallumokban fut le.
Az \textbf{üzleti logika} lényegében minden egyéb, ami nem platform specifikus. Felépítése egy három fázisú csővezeték. Az első fázisban a platform illesztőn keresztül megkap egy szenzor adatot. Ez lehet egy hangfájl a mikrofonról de bármilyen más szenzortól származó mérési érték is. Ezután egy előfeldolgozó lépés következik, amely képes döntést hozni arról, hogy az adott mérést továbbítsa-e a következő fázisra, amely egy ideális protokollon elküldi a hangmintát a felhőbe. A folyamat egy időzítő által meghatározott intervallumokban fut le.
Jelenleg az üzleti logikában lévő csővezeték második fázisaként van implementálva az \acrshort{svm} alapú algoritmus. Így csak akkor továbbítja a hangmintát a felhő felé, ha madárhangot észlelt.
							
							
							
								
							
						
@@ -99,7 +99,7 @@ Emellett az üzleti logikában van implementálva a felhőből érkező parancso
A szoftver \gls{python} nyelven került implementálásra. A telepítése közvetlenül Git használatával történik ezzel is megkönnyítve a fejlesztési és tesztelési folyamatokat. 
\subsection{\Gls{felho} rendszer}
\subsection{Felhő rendszer}
A felhőrendszer mikroszolgáltatás architektúrát használva került megvalósításra. Ez azért indokolt, mert így az egyes komponenseket könnyen lehet skálázni, ami egy ilyen sok végeszközt kiszolgáló rendszernél előny. Emellett bizonyos komponensei könnyen kicserélhetőek. Erre szükség is volt egyszer, amikor lecserélésre került a használt \acrshort{mi} algoritmus. 
							
							
							
								
							
						
@@ -115,7 +115,7 @@ A rendszerbe érkező összes hangminta a beérkezés pontján címkézésre ker
\begin{figure}[h!]
	\centering
	\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
	\caption{A \gls{felho} szoftver architekturális felépítése}
	\caption{A felhő szoftver architekturális felépítése}
	\label{fig:architecture-redesigned}
\end{figure}
							
								
							
							
								
							
							
						
@@ -176,7 +176,7 @@ A mikroszolgáltatás architektúrának és a megfelelő tervezésnek köszönhe
\subsection{Kommunikáció}
Az \acrshort{iot} eszközök a \gls{felho}vel való kommunikáció során hibrid módon használnak \acrfull{http} vagy \acrfull{mqtt} protokollt. Ezt a hibrid megoldást indokolja, hogy előfordul, hogy az eszközöknek nagy méretű fájlokat kell feltöltenie (Hangmintákat) illetve időnként szintén nagy méretű fájlokat kell letöltenie (\acrshort{mi} modellek). Viszont mindkét esetben a kezdeményező fél maga az \acrshort{iot} eszköz. Ilyenkor az eszköz a felhőhöz csatlakozik, amihez könnyű egy jól ismert címet társítani.
Az \acrshort{iot} eszközök a felhővel való kommunikáció során hibrid módon használnak \acrfull{http} vagy \acrfull{mqtt} protokollt. Ezt a hibrid megoldást indokolja, hogy előfordul, hogy az eszközöknek nagy méretű fájlokat kell feltöltenie (Hangmintákat) illetve időnként szintén nagy méretű fájlokat kell letöltenie (\acrshort{mi} modellek). Viszont mindkét esetben a kezdeményező fél maga az \acrshort{iot} eszköz. Ilyenkor az eszköz a felhőhöz csatlakozik, amihez könnyű egy jól ismert címet társítani.
Emellett időnként szükség van \enquote{kis} adatok átvitelére mindkét irányba. Ilyenkor a felhő is küldhet az eszközöknek parancsot. Az eszközök címei, ha ismertek is, a fogyó \acrshort{ipv4} címek és az \acrshort{ipv6} hálózatok hiánya miatt valószínűleg \acrfull{nat} által határolt hálózatban lennének, ami megnehezíti a felhőből az eszközökhöz való csatlakozást ezzel a \acrshort{http} használatát is. Mivel a felhő felé továbbra is megoldott a csatlakozás és az átvitel tárgyát képező információk méretben kicsik, ezért erre a feladatra az \acrshort{mqtt} használtuk, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve.