2021-05-20 18:36:03 +02:00
parent f7d408e470
commit 83445c5b7c
4 changed files with 114 additions and 12 deletions
							
							
								
							
							
						
@@ -89,16 +89,35 @@ 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.
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. 
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.
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 az alábbiak:
\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}
\begin{figure}[h!]
	\centering
	\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
							
							
							
								
							
						
@@ -106,16 +125,57 @@ A szoftver \gls{python} nyelven került implementálásra. A telepítése közve
	\label{fig:architecture-redesigned}
\end{figure}
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}
\begin{itemize}
	\item \textbf{Input Service} 
	\item \textbf{Storage Service}
	
	\item \textbf{\acrshort{ai} Service}
		
	\item \textbf{Model Service}
			
	\item \textbf{Results Service}
	\item \textbf{Metrics Service}
	
	\item \textbf{Guard Service}
	\item \textbf{Command and Control Service}
		
\end{itemize}
\subsubsection{Használt külső fejlesztésű szoftverek}
\begin{itemize}
	\item \textbf{PostgreSQL}
	\item \textbf{MinIO}
	
	\item \textbf{InfluxDB}
		
	\item \textbf{RabbitMQ}
		
\end{itemize}
\subsection{Kommunikáció}
% HTTP és MQTT hibrid megoldás
% Nat meg adat méret
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