marci-dipterv-latex/src/content/birbnetes_impl.tex

% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Madárhang felismerő rendszer implementáció}
\label{chapter:birbnetes}
%----------------------------------------------------------------------------

Éves szinten komoly károkat tudnak okozni a szőlőtermő vidékeken a termést előszeretettel fogyasztó seregély madarak\cite{seregelykar}. Jelenleg kevés hatékony megoldás van arra, hogy a szőlősgazdák meg tudják védeni a termést a kártékony madaraktól\cite{nk}.

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.

\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.


\subsection{Intelligens felismerés}


A hangminták felismerése egy két szintű \acrfull{mi} rendszerben történik. Az első szint egy egyszerűbb \acrfull{svm} alapú algoritmus, amely egyfajta előszűrést végez a rögzített hangmintákon. Kiválasztja azokat a hangmintákat, amelyek nagy eséllyel tartalmaznak madár hangot.

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 miatt az \acrshort{iot} eszközökön, 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. 

Az elméleti működéséről az algoritmusoknak a következő fejezetek adnak áttekintést.

\subsubsection{\acrlong{svm}}

A gépi tanulás kontextusában az \acrshort{svm} egy felügyelt tanulási módszer, amelyet többek között a klasszifikációs feladatok megoldására tudnak eredményesen használni\cite{scikit_svm}. Fontos előnye, hogy nagyon hatékonynak tekinthető az erőforrás használat szempontjából.

Működésének alapját az adja, hogy úgy próbálja az adathalmazt felosztani osztályokra, hogy megkeresi egy vélt választó vonalhoz legközelebb eső pontokat (support vectorokat), majd azon dolgozik hogy a választó vonal és ezen pontok távolsága a legnagyobb legyen. Az algoritmus egyszerű dimenzióváltásoknak köszönhetően nagyon hatékonyan tud magasabb dimenziókban is problémát megoldani\cite{medium_svm}.


% TODO Ide szülni még egy bekezdést, hogy az itt hogy jó nekünk

\subsubsection{Konvolúciós Neurális Hálók}


A neurális hálók működésükben és felépítésükben a leginkább hasonlítanak az emberi agy működésére. Mint azt a neve is mutatja, neuronokból áll. Minden egyes neuronnak van egy bemenete és egy kimenete. A neuronok belsejében pedig egy aktivációs függvény van, amely alapján a kimenetet számolja. Ezeket a neuronokat rétegekbe szervezik, és oly módon kötik össze őket, hogy az egyes rétegekben lévő neuronok, az előttük lévő réteg kimenetét kapják meg bemenet gyanánt. Egy ilyen konstrukciót nevezünk neurális hálónak\cite{medium_nn}. A háló minden éle rendelkezik úgynevezett súlyozással, itt mi ezeknek a súlyozásoknak az összességét és magának a hálónak a felépítését egy csomagban modellnek nevezzük.

A konvolúciós neurális hálóknak (\acrlong{cnn}; \acrshort{cnn}) nagyon széles felhasználási köre van, a mozgókép felismeréstől az ajánló rendszereken át a természetes nyelvfeldolgozásig. A konvolúciós neurális hálók a neurális hálók egy speciális fajtája, ahol az egyes rétegek konvolúciót valósítanak meg\cite{medium_cnn}.

Az alkalmazott megoldás a beérkező hangokból spektrogramot generál, majd ezeket képként értelmezve végez rajtuk felismerést. Mivel a konvolúciós neurális hálókat eredményesen használják képfelismerésre, ezért ez egy kézenfekvő megoldás itt is.

\subsection{Telepített eszköz}

A termőföldre telepített eszközök alacsony áramfogyasztású és következésképp csekély számítási teljesítményű hardverek.

A telepítés helyének adottságaiból fakadóan, fontos, hogy képesek legyenek valamilyen rádiós interfészen kommunikálni. Mivel a szőlő termő vidékeken ritkán áll rendelkezésre megfelelő vezetékesen kiépített informatikai infrastruktúra. Illetve a termőföldek sokasága és mérete miatt sem könnyen kivitelezhető ez.

Munkánk során egy ilyen eszköz prototípusát is elkészítettük mind hardver mind szoftver tekintetében. Fontosnak tartottuk a platform bővíthetőségét, így ezt figyelembe véve terveztük meg azt. 

\subsubsection{Hardver}

A hardver lényegében egy számítógép a szükséges perifériákkal együtt egy dobozba szerelve. A rendszer lelkét adó számítógép egy \acrfull{rpi} mikroszámítógép 4-es modellje. Ez a modell 4 magos ARM processzorral és 8 Gigabyte memóriával rendelkezik. Ennek az az oka, hogy nem szerettük volna, ha már a fejlesztés szakaszában hardveres limitációkba ütköznénk. Azt szerettük volna, ha kész a rendszer akkor konkrét mérésekre és számításokra tudjuk alapozni a hardverválasztást, de addig ne legyen ebből probléma. Népszerűségének köszönhetően a \acrlong{rpi} kellően jó közösségi támogatással rendelkezik mind hardveres mind pedig szoftveres szempontból.

Az eszköz bemenetéül egy USB mikrofon szolgál. Ez egy egyszerű széles hatókörű konferencia mikrofon, amely eredeti funkcióját tekintve arra szolgál, hogy az asztal közepén az asztal körül ülők hangját képes legyen venni. így a tesztkörnyezetünkhöz is megfelelő lefedettséggel rendelkezik.

Az eszköz moduláris jellegéből adódóan természetesen több adatforrás is csatlakoztatható rá, ilyen lehet például hőmérséklet vagy fény érzékelő. Ezeket akár általános adatgyűjtés mellett a detekció pontosságának javítására is fel lehet használni. 

Az eszköz visszajelzésre több megoldással is rendelkezik. Elsősorban három különböző színű \acrshort{led} izzóval rendelkezik (piros, zöld és kék), amelyeket szoftveresen lehet vezérelni. Ezek különböző fontos eseményekre vagy állapotokra tudják felhívni a figyelmet.

Emellett a prototípus tartalmaz egy hangszórót és egy D osztályú erősítőt, amellyel állítható hangerővel különböző hangok játszhatóak le. Ez egy demó környezet esetén lehet a seregély madár természetes ellenségeinek hangmintája is.

A vezeték nélküli kommunikációs interfésze az eszköznek nincs fixen rögzítve. Az adott környezetnek és tesztesetnek megfelelő kiegészítővel látjuk el, ha szükség van rá. Ez lehet \acrshort{wifi} de \gls{4g} vagy akár \gls{5g} is.

A prototípus egy műanyag házba van beszerelve. Az összeszerelt prototípus \aref{fig:doboz}.\ ábrán látható. A fejlesztés és tesztelés megkönnyítésére egy RJ45-ös csatlakozó is beépítésre került, amelynek segítségével csatlakozhatunk az eszközre \acrshort{ip} protokoll felett. Az összeszerelés -- annak egyszerűségéből adódóan -- kézzel történt.

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.8\textwidth]{figures/doboz}
	\caption{Összeszerelt prototípusa a telepített \acrshort{iot} eszköznek}
	\label{fig:doboz}
\end{figure}

Az eszköz tápellátása 5V-on történik, a használt tápegység 3A áram leadására képes, tapasztalatink szerint ez elegendő az eszköz stabil működtetésére.


\subsubsection{Szoftver}

A szoftverkörnyezet alapjául szolgáló operációs rendszer egy \textit{Debian}\footnote{\url{https://www.debian.org/}} alapú rendszer (\textit{Raspbian}) fut. Ez egy népszerű és jól dokumentált operációs rendszer.

Az erre telepített szoftver komponens két részre bontható. Platform függő \textbf{platform-illesztőre} és platform független \textbf{üzleti logikára}. 

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.

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.

Emellett az üzleti logikában van implementálva a felhőből érkező parancsok feldolgozása és végrehajtása is. Jelenleg ez demó jelleggel egy "alvó mód" parancs van implementálva, amellyel az eszközt alacsony energia felhasználású módba lehet kapcsolni amelynek során nem rögzít vagy küld hangmintákat. Illetve egy "riasztás" parancs, amelyre előre felvett hangmintákat játszik le a hangszórón.

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}

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. 

A rendszer fő része lényegében itt is egy csővezetéket (más néven feldolgozó szalagot) valósít meg, amelynek belépési pontja az \textit{Input Service} és kimenetei a hangmintákon végzett predikciók vagy esetlegesen automatizált riasztások az \acrshort{iot} eszközök felé. A feldolgozó szalag fázisai az egyes mikroszolgáltatások, amelyek önállóan tolják tovább az adatot mindig a következő szolgáltatásnak.

A mikroszolgáltatások az egymással való kommunikáció során \acrshort{http} \acrfull{rest} (reprezentatív
állapot transzfer) \acrshort{api}-t használnak. Kivéve kettő helyen. Azokon a pontokon ahol több irányba mehet tovább a végrehajtás (miután egy hangfájl beérkezett vagy arról elkészült a predikció) ott az ezt támogató üzenetsor került alkalmazásra. Így lehet, hogy egy predikció eredménye egyszerre eltárolásra kerül és az alapján parancsot küldjön az eszközöknek a riasztásra.

Az egyes szolgáltatások között mindig csak a legkisebb hasznos adat kerül továbbításra, ezzel optimalizálva az adatforgalmat az egyes komponensek között, csökkentve a redundáns adat átviteleket (például a hangminta nem kerül elküldésre az egyes szolgáltatások közt csak annak az azonosítója). Ez a megfontolás lehetőséget ad a gyorsítótárazás implementálására is. 

A rendszerbe érkező összes hangminta a beérkezés pontján címkézésre kerül. Később a feldolgozó szalag egyes fázisain ezzel lehet hivatkozni egy konkrét hangmintára. Ezek a címkék biztosítottan egyediek a rendszeren belül.

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
	\caption{A \gls{felho} szoftver architekturális felépítése}
	\label{fig:architecture-redesigned}
\end{figure}

A rendszert alkotó mikroszolgáltatások négy fő csoportra oszthatóak. Ezt a felosztást mutatja be \aref{fig:architecture-redesigned}.\ ábra. Röviden ezek a csoportok a következőek:
\begin{itemize}
	\item \textbf{West-End Subsystem} Az itt található szolgáltatások felelnek a beérkező hangfájlok és egyéb mérések adminisztrációjáért. 
	\item \textbf{AI Subsystem} Ezek a szolgáltatások felelnek az intelligens felismerésért.
	\item \textbf{East-End Subsystem} Az intelligens felismerés eredményének hatására aktiválódó szolgáltatások vannak itt. 
	\item \textbf{Device Subsystem} Azok a szolgáltatások, amelyek közvetlenül az eszközök vezérlésért, azok adminisztrációjáért felelnek.
\end{itemize}



A rendszerhez készült egy webes kezelőfelület is, amelyet hallgatótársunk Kunkli Richárd fejlesztett.


\subsubsection{Implementált mikroszolgáltatások}

Az általunk tervezett és implementált mikroszolgáltatások működéséről és felelősségeiről egy rövid leírás olvasható az alábbiakban.

\begin{itemize}
	\item \textbf{Input Service} Ez az a szolgáltatás amely a felhőbe érkező hangfájlokat fogadja. Ennek a szolgáltatásnak a felelőssége ellátni az egyes hangmintákat címkével. Ezeket a címkéket lokálisan egy relációs adatbázisban is letárolja a hangfájlhoz tartozó egyéb információkkal együtt. A fogadott hangfájlt továbbküldi a \textit{Storage Service} számára. Miután az sikeresen eltárolta, ez a szolgáltatás az üzenetsorba publikál egy üzenetet hogy értesítse a feliratkozókat az új hangminta érkezéséről.

	\item \textbf{Storage Service} Ez a szolgáltatás valósítja meg a hangfájlok hosszútávú tárolását egy objektum tárolóban. Képes kérésre visszaadni a hangfájlokat, illetve törölni is a mintákat.
	
		
	\item \textbf{\acrshort{ai} Service} Ez a szolgáltatás valósítja meg a beérkezett hangmintán hallható madár hang konkrét azonosítását. Ehhez \acrshort{cnn} algoritmust használ. Mind a folyamat elkezdéséhez szükséges üzenet fogadását, mind az eredmény publikálását üzenet sorokra kapcsolódva valósítja meg. A működéséhez szükséges modellt a \textit{Model Service} komponensből tölti le, amellyel \acrshort{rest} interfészen kommunikál. A hangmintát tag alapján a \textit{Storage Service}-ből tölti le címke alapján. Az adott eredmény egy hangminta címkéje és a felismert osztály (amely modelltől függően egy madár faj lehet).
		
	\item \textbf{Model Service} Ez egyfajta okos tároló a rendszerben használt különböző \acrshort{mi} algoritmusok által használt modellek tárolására és kezelésére. Nem csak magát a modellt de arról különböző metaadatokat is képes eltárolni, amelyeket automatikusan olvas be a modellből. Ilyen például, hogy milyen modelleket képes azonosítani, ezekből melyik jelent veszélyt vagy, hogy az előfeldolgozásánál a hangnak milyen paramétereket kell használni.
			
	\item \textbf{Results Service} Ez a szolgáltatás az egyes mintákra való kiértékelések eredményét tárolja le. Minden mintára az eredmények egyértelműen visszakereshetőek és lekérdezhetőek. Ennek a megoldására relációs adatbázist használ.

	\item \textbf{Metrics Service} Az előző szolgáltatással ellenben ez a szolgáltatás az eredményeket időben változó metrikaként kezeli. Elabsztrahálja az egyes mintákat és statisztikai adatokat kezel. Ez különösen hasznos lehet bizonyos elemzéseknél és vizualizálásoknál.
	
	\item \textbf{Guard Service} Ez a szolgáltatás is a mérések eredményét kapja meg a bemenetén, de itt nem eltárolja azokat, hanem ha az bizonyos határértéket átlép, akkor parancsot küld a termőföldre telepített \acrshort{iot} eszközöknek, hogy kezdjék meg a madarak elriasztását.

	\item \textbf{Command and Control Service} Ez a szolgáltatás egy olyan interfészt valósít meg, amelyen keresztül egyszerűen lehet eszközöket, vagy azok egy csoportját kezelni. Azoknak lehet parancsot küldeni, vagy az állapotukat lekérdezni. Az eszközökkel \acrshort{mqtt} interfészen kommunikál, míg önmaga egy \acrshort{rest} interfészt szolgál ki.
		
\end{itemize}

\subsubsection{Használt külső fejlesztésű szoftverek}

Az alkalmazás több "off-the-self" komponenst is használ ahhoz, hogy megvalósítsa a tervezett működést. Ezeket mi választottunk ki a tervezés során. A következőkben csak röviden bemutatom ezeket a komponenseket és a kiválasztásának okát.

\begin{itemize}
	\item \textbf{PostgreSQL} (Relációs Adatbázis): Második legnépszerűbb nyílt forráskódú relációs adatbázis kezelő rendszer, kifejezetten alacsony erőforrás igényekkel, valamint igen fejlett képességekkel rendelkezik. Rendkívül jó a közösségi támogatása. A fejlesztés előtt volt már vele korábbi tapasztalatunk.

	\item \textbf{MinIO} (Objektum tár): Nagy teljesítményű Objektum tár, amely az Amazon S3 \acrshort{api}-ját implementálja. Egyenesen \textit{Kubernetes} környezetbe tervezve. Egyszerűen használható és telepíthető. Emellett rendelkezik a fejlesztőktől származó \gls{python} implementációval, melyhez könnyen kezelhető \textit{Flask} plugin is tartozik.
	
	\item \textbf{InfluxDB} (Idősoros adatbázis): Az \textit{Influx Data} által fejlesztett idősoros adatbázis. Rendkívül hatékonyan tud az adatokon műveleteket végezni, az \acrshort{api} kezelése egyszerű és intuitív. A fejlesztés előtt volt már vele korábbi tapasztalatunk.
		
	\item \textbf{RabbitMQ} (Üzenetsor): \textit{Erlangban} írt, népszerű, nyílt forráskódú üzenetsort megvalósító rendszer. Kezelése kifejezetten egyszerű és rendelkezik \gls{python} \acrshort{api}-val, valamint rendkívül jó minőségű dokumentáció érhető el hozzá.
	
		
\end{itemize}

A mikroszolgáltatás architektúrának és a megfelelő tervezésnek köszönhetően ezek a technológiák könnyen lecserélhetőek. Kizárólag az adott komponenssel közvetlenül kommunikáló szolgáltatást kell módosítani.

\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.

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ált, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve.


\section{Tervezés}

% Itt leírom az átalakítást a három rétegű pörgő lófaszra

% Még jó, hogy mikro meme, meg k8s, így tök véletlenül pont a kubeedge a legjobb framework hozzá

% a szükséges átalakításokat összeszedem

% Végül az elkészült műdől is írok pár sort és hogy miért jó ez nekünk
% = hogy lehet ezzel megmutatni, hogy miért jó a kenyér és a héja