2021-12-17 18:43:14 +01:00
parent b2ccc73bfa
commit aa3b8d6b47
3 changed files with 65 additions and 45 deletions
							
							
								
							
							
						
@@ -38,19 +38,18 @@ Működés közben az \acrshort{iot} eszközök folyamatosan rögzítik a hangmi
\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, továbbra is számottevő tud lenni, különösen 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 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 gigabites sávszélességi igénye van.
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ák tömörítése természetükből adódóan nem lehetséges veszteségmentesen számottevő módon tömöríteni \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 vonások % <- feature magyarul
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. 
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 szegmensre és lefuttattam rájuk a felismerő algoritmust. Az eredményeket \aref{tab:proof_maker}.\ táblázat foglalja össze.
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
							
							
							
								
							
						
@@ -71,15 +70,15 @@ Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni
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 kell az összes, csak a gyanús mintákat elküldeni elemzésre a felhőbe. Emellett a peremhálózati rendszereken sokkal jobban skálázódhat az alkalmazás. Emellett 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.
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{ml} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. 
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 proxyké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.
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
							
							
							
								
							
						
@@ -98,20 +97,20 @@ A mikroszolgáltatás fejlesztését \gls{python} nyelven végeztem. Azért ezt
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ők segítségével a projekt többi területén is használom ezért választottam itt is ezt.
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ős 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, hogy megtartsa. 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 több ideig is eltarthat, előfordulhat, hogy egy komponenshez egyszerre több kérés is beérkezik, ez csak tovább rontaná a válaszidőt. 
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.
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. Későbbi használatra betöltve tartja.
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.
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.
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.