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

Éves szinten komoly károkat okoznak a szőlőtermő vidékeken a seregély madarak, amelyek előszeretettel csipegetik le a megtermelt szőlőt. A seregély védett madár és a jelenlegi vadkár elleni megoldások vagy drágák vagy nem túl hatékonyak \cite{nk}. A probléma innovatív megoldására irányult az a tanszéki projekt, -- amelyen én is részt vettem -- amely olyan rendszer kidolgozását tűzte ki célul, amely a madarakat képes hangjuk alapján azonosítani, illetve szükség esetén elriasztani őket. 

A rendszer eredetileg a szőlővidékre telepített \acrfull{iot} eszközökből és a felhőben futó szoftverből áll. Kétszintű mesterséges intelligencia segítségével mind az eszközök, mind a felhő szoftver végez intelligens felismerést. Az eszköz maga egy egyszerűbb algoritmussal próbálja megállapítani, hogy a rögzített hangminta tartalmaz-e madárcsiripelést. Ha igen, továbbítja a mintát a felhőbe, ahol egy komolyabb számítási igényű mesterséges intelligencia osztályozza a mintát aszerint, hogy milyen madár hangját tartalmazza a minta. Ha a felismerés eredménye arra utal, hogy a cél madár hangját sikerült rögzíteni, akkor a rendszer megpróbálkozik a kérdéses madár elriasztásával hangminták lejátszásával a területen telepített eszközön.

A rendszer belső működéséről egy rövid összefoglaló található \aref{appendix:birbnetes}.\ függelékben. A fejezeten belül csak a permhálózati alkalmazásra való átalakítás szempontjából érintett részleteket vázolom.

Ez az alkalmazás a peremhálózati rendszerek adat aggregációs lehetőségeit hivatott kiaknázni. Azzal, hogy bevonjuk a peremhálózati rendszereket a működésbe, jelentős adatforgalmi és számítási kapacitásbeli megtakarításokat érhetünk el. 


\section{Felépítés}
\label{sec:birbnetes_short_desc}

A rendszer felépítése két rétegű. Az egyik réteg a felhőben futó szoftver a másik magukon az \acrshort{iot} eszközökön fut. A két rendszer magas szintű működésének funkcionális vázlatát \aref{fig:nagyon_simple_birbnetes}.\ ábra szemlélteti. 


\begin{figure}[h!]
	\centering
	\includegraphics[width=0.9\textwidth]{figures/nagyon_simple_birbnetes}
	\caption{Madárhang felismerő rendszer egyszerűsített architektúrája}
	\label{fig:nagyon_simple_birbnetes}
\end{figure}


A felhős szoftver felépítése mikroszolgáltatás architektúrára épül. Az egyes funkcionalitásokat különálló mikroszolgáltatások valósítják meg, a futtatókörnyezet \textit{Kubernetes}. A hangminta feldolgozására szolgáló intelligens felismerésen kívül ez a komponens megvalósít számos egyéb funkcionalitást is, mint a hangminták hosszútávú tárolása, a használt \acrshort{mi} modellek kezelése vagy az észlelésekről statisztikai adatok készítése és azok vizualizálása.

Az \acrshort{iot} eszközön futó komponens egy moduláris monolit szoftver. Két részből áll: üzleti logika és platform illesztő. A platform illesztő egy absztrakciós réteget húz a konkrét hardver belső működése fölé és egységes interfészt szolgáltat az üzleti logika számára. 

A két réteg kommunikációja két külön csatornán történik. Az egyik csatorna a vezérlő és állapot üzenetek kétirányú továbbítására szolgál. Ez egy \textit{MQTT} alapú üzenetsor. A másik csatorna a rögzített hangminták feltöltésére szolgál, ez \acrshort{http} kapcsolaton keresztül történik. 

Működés közben az \acrshort{iot} eszközök folyamatosan rögzítik a hangmintákat egy másodperces darabokban. Minden egyes mintára lefuttatják a helyi mesterséges intelligencia alapú felismerő algoritmusukat. Ha annak az eredménye arra enged következtetni, hogy a hangmintán madárcsiripelés hallható, akkor a minta felküldésre kerül a felhőbe. Az felküldött \acrshort{http} üzenetben a hangminta maga és néhány információ utazik az eszközről és a rögzítés körülményeiről.

\section{Felkészítés peremhálózati alkalmazásra}

\subsection{Motiváció}

Az eredeti szoftver architektúrában az \acrshort{iot} eszközök közvetlenül kommunikálnak a felhővel. Az eszközökön futó \acrshort{mi} komponens jelentősen csökkenti a hálózati terhelést, de cserébe az \acrshort{iot} eszköznek képesnek kell lennie futtatni a komponenst, amelynek ugyan a felhőben futó kiértékelő szoftvernél kevesebb a számítási igénye, de továbbra is számottevő tud lenni. Különösen fontos ez az eszközök tömegtermelésénél, ahol eszközönként pár cent különbség is sokat jelenthet. Ha meg tudjuk spórolni ezt a funkcionalitást, akkor azzal jelentős költség megtakarítást tudunk elérni, kisebb teljesítményű, energiatakarékos hardverek alkalmazása révén.

Az első szintű \acrshort{mi} alapú szűrés teljes eltávolítása viszont nem minden esetben járható út. Megtehetjük, hogy ezt a fázist a felhőbe \enquote{költöztetjük}. Ám ebben az esetben az összes rögzített hangmintát minden eszköznek fel kell küldenie a felhőbe. Az alábbi számításból kiderül, hogy -- a jelenlegi hangminőségi beállítások szerint -- mindössze alig több mint 1400 darab eszköznek együttesen már átlagosan gigabites sávszélesség igénye van, ha folyamatosan és egyszerre küldenek hangmintákat.

$$ 44100\textrm{Hz} \cdot 16\textrm{bit} = 88.2\textrm{kbyte/s} = 705.6\textrm{kbit/s} = 0.7056\textrm{Mbit/s}$$
%$$ 1\textrm{Gbit/s} = 1000\textrm{Mbit/s}  $$
$$ \dfrac{1000\textrm{Mbit/s}}{0.7056\textrm{Mbit/s}} = 1417.2334$$


A hangmintákat természetükből adódóan nem lehetséges számottevő módon tömöríteni, úgy hogy teljesen veszteségmentes legyen \cite{audio_quality}. Veszteséges tömörítéssel jelentős megtakarítást lehetne elérni, ám ekkor félő, hogy elvesznek olyan jellemzők is, amelyek hiánya negatívan befolyásolja a felismerés hatékonyságát. Ezért mindenképpen az eredeti minőségében kell a felvételeket továbbítani. 

Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni, hiszen nagyban függ az évszaktól, napszaktól, a tájegységtől, időjárástól a környező élővilágtól és egyéb hatásoktól, körülményektől. A hatékonyság megbecsléséhez -- kizárólag szemléltető célzattal -- összegyűjtöttem néhány -- a célterülethez hasonló -- hangfelvételt az internetről. Ezeket felbontottam egy másodperces szegmensekre és lefuttattam rájuk a felismerő algoritmust. Az eredményeket \aref{tab:proof_maker}.\ táblázat foglalja össze.

\begin{table}[h!]
	\centering
	\begin{tabular}{|l|c|c|c|}
		\hline
		\textbf{Minta} & \textbf{Összes Sz.} & \textbf{Továbbított Sz.} & \textbf{Arány} \\
		\hline
		\hline
		Eredeti Tanító minta részlet & 190 & 152 & 80.0\% \\
		Erdei hangfelvétel madárcsiripeléssel & 1000 & 288 & 28.8\% \\
		Erdő, kevés madárcsiripeléssel & 316 & 53 & 16.7\% \\
		Éjszaka, havazás & 1500 & 1 & 0.06\% \\
		\hline
	\end{tabular}
	\caption{Első fázisú \acrshort{mi} áteresztésének vizsgálata különböző hangmintákra}
	\label{tab:proof_maker}
\end{table}

Beláthatjuk, hogy az intelligens felismeréssel jelentős sávszélességet tudunk megtakarítani. A felhőbe felküldött, de nem madárcsiripelést tartalmazó minták felesleges hálózati terhelést jelentenek, hiszen ellenőrzés után eldobásra kerülnek. 

Ennek a problémának a megoldására nyújt lehetőséget a peremhálózati rendszer bevonása. Mivel a peremhálózati rendszer sokkal elosztottabb és logikailag közelebb van az adatok forrásához, ezért képesek vagyunk vele egyszerre kevesebb eszközt kiszolgálni sokkal alacsonyabb adatforgalmi költségek mellett, hiszen nem az összes, hanem csak a gyanús mintákat kell elküldeni elemzésre a felhőbe. Emellett a peremhálózati rendszereken sokkal jobban skálázódhat az alkalmazás. Ezeken felül a megosztott erőforrásoknak is hasznát vehetjük, ha egyes \acrshort{iot} eszközöket leállítunk (például télen, amikor nem fenyeget madár veszély) akkor nem fog kihasználatlanul állni az eszközökben az extra számítási kapacitás, hiszen a peremhálózati felhőrendszerbe könnyen be tudunk ütemezni más feladatokat.

\subsection{Tervezés}

A tervezés során fontosnak tartottam, hogy a rendszer többi komponensében minimális változtatásokat kelljen tenni. Az eredeti rendszer mikroszolgáltatás architektúrára épült, így az egyes komponensek felelőssége jól elkülönül. A megtervezett architektúrába könnyen beilleszthető extra funkcionalitás. 

Mivel \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{KubeFed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{mi} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. 

Az \acrshort{iot} eszközön futó szoftver \acrshort{http} interfészen keresztül tölti fel a mintákat. Az új mikroszolgáltatást proxy-ként terveztem meg, azaz egy ugyanolyan \acrshort{http} interfészt szolgál ki, mint a felhőben a hangfájlok fogadására szolgáló végpont. Ha az \acrshort{ml} algoritmus madárcsiripelést azonosít a mintában, akkor azt módosítás nélkül továbbküldi,  így az eszközök és a felhő számára is teljesen transzparens módon tud működni az új szolgáltatás. A megváltozott architektúráról \aref{fig:birbnetes_super_simple_services}.\ ábra ad vázlatos áttekintést. Ez a szolgáltatás egyformán futhat a felhőben, de a peremen is, nincsenek lokalitási kötöttségei.

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.9\textwidth]{figures/birbnetes_super_simple_services}
	\caption{Megváltoztatott architektúra a peremhálózati rendszer bevonásával.}
	\label{fig:birbnetes_super_simple_services}
\end{figure}

Emellett természetesen a jelenlegi \acrshort{iot} szoftverben is módosítást kell végezni, hogy ne használja a beépített \acrshort{ml} algoritmust. Ez a fejlesztés és tervezés során ideális, ha konfigurálható módon ki és be kapcsolható. De később teljesen el lehet távolítani az intelligens felismerésért felelős szoftver komponenst.

\subsection{Implementáció}

\subsubsection{Előszűrő szolgáltatás}
\label{sec:prefilter_service_implementation}

A mikroszolgáltatás fejlesztését \gls{python} nyelven végeztem. Azért ezt választottam, mert az \acrshort{iot} eszközön futó szoftver korábban abban íródott, ezért a releváns komponenseket könnyen át tudtam emelni.

A szoftverkomponens funkcionalitását tekintve három fő funkcionalitást kell megvalósítania. Ezek a \acrshort{http} kérések fogadása, intelligens felismerés futtatása, majd eredménytől függően újabb \acrshort{http} kérés indítása.

A \acrshort{http} interfész megvalósítására a \textit{Flask}\footnote{\url{https://flask.palletsprojects.com/}} mikrokeretrendszert használtam. Ez a keretrendszer könnyen bővíthető további letölthető beépülő modulok segítségével, a projekt többi területén is használom, ezért választottam itt is ezt.

A felhőben futó szoftver egy hangminta fogadása után egyből visszatér a válasszal. Ezt a viselkedést az új komponensestől is elvárhatjuk, ezért az nem egy jó megközelítés, hogy a kérés hatására a kérés kezelésének részeként hajtjuk végre az intelligens felismerést, hiszen ez olykor sokáig is eltarthat, valamint előfordulhat, hogy egy komponenshez egyszerre több kérés is beérkezik, ami csak tovább rontaná a válaszidőt. 

Ennek a problémának a megoldására az \textit{uWSGI}\footnote{\url{https://github.com/unbit/uwsgi}} futtató környezetet használtam. Ez a futtatókörnyezet lehetőséget ad arra, hogy párhuzamosan futó programkódot futtassunk a webes alkalmazásuk mellett, amellyel a webes része az alkalmazásunknak egy sor segítségével tud kommunikálni. Új hangminta érkezésekor az bekerül ebbe a várakozási sorba. Ebből a sorból egy párhuzamosan futó programrész veszi ki, futtatja le az intelligens felismerést, és szükség esetén indítja a további \acrshort{http} kérést, amely tartalmilag megegyezik a hozzá beérkezett eredeti kéréssel.

A felismerő algoritmusnak szüksége van egy modell fájlra a működéséhez. Ez a modellfájlt tartalmazza a mesterséges intelligencia paramétereit. Ezeket a felhőből lehet letölteni, az \acrshort{iot} eszköz is innen tölti le, ha szüksége van rá. Ugyanezt a viselkedést implementáltam a mikroszolgáltatásba is. Futtatás előtt ellenőrzi, hogy rendelkezésére áll-e a modell. Ha nem, akkor \acrshort{http} kérés segítségével letölti azt a felhőből és betölti, valamint későbbi használatra betöltve tartja.

\subsubsection{\acrshort{iot} szoftver módosítása}

Az \acrshort{iot} eszköz szoftverén ahhoz, hogy megvalósítsam a tervekben foglaltat, felvettem egy új konfigurációs változót. Ennek segítségével ki lehet kapcsolni a beépített intelligens szűrés futtatását.

A szoftveren belül az intelligens felismerést egy osztály valósítja meg. Megoldásomban létrehoztam egy osztályt, amelynek ugyanaz az interfésze, mint az intelligens felismerő osztálynak, de felismerés helyett mindig felküldésre ítéli a hangmintákat. 

A konfigurációs beállítás a példányosításnál játszik szerepet, azt befolyásolja hogy az eredeti osztály, vagy a fent vázolt osztályból jöjjön létre példány.


