Added more stuff about frameworks

src/content/birbnetes_impl.tex

@@ -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
+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.
-% Nat meg adat méret
+
+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

src/content/glossary.tex

@@ -113,7 +113,7 @@
 \newglossaryentry{python}
 {
 	name={Python},
-	description={A Python egy általános célú, magas szintű interpretált programozási nyelv. Fejlesztését 1989-ben kezdte Guido van Rossum}
+	description={A Python egy általános célú, magas szintű interpretált programozási nyelv. Fejlesztését 1989-ben kezdte Guido van Rossum. Jelenleg legfrissebb verziója a 3.9 amely 2020 Októberében került kiadásra}
 }
 
 \newglossaryentry{devops}
@@ -174,6 +174,8 @@
 \newacronym{tls}{TLS}{Transport Layer Security}
 \newacronym{ssl}{SSL}{Secure Sockets Layer}
 \newacronym{ip}{IP}{Internet Protocol}
+\newacronym{ipv4}{IPv4}{Internet Protocol version 4}
+\newacronym{ipv6}{IPv6}{Internet Protocol version 6}
 \newacronym{rfc}{RFC}{Request for Comments}
 \newacronym{gnu}{GNU}{GNU's Not Unix!}
 \newacronym{html}{HTML}{HyperText Markup Language}
@@ -210,4 +212,7 @@
 \newacronym{rpi}{RPi}{Raspberry Pi}
 \newacronym{led}{LED}{Light Emitting Diode}
 \newacronym{mi}{MI}{Mesterséges Intelligencia}
-\newacronym{wifi}{WiFi}{Wireless Fidelity}
+\newacronym{wifi}{WiFi}{Wireless Fidelity}
+\newacronym{mqtt}{MQTT}{Message Queuing Telemetry Transport}
+\newacronym{aws}{AWS}{Amazon Web Services}
+\newacronym{io}{I/O}{Input/Output}

src/content/overview.tex

@@ -168,10 +168,27 @@ Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a
 
 \subsection{Project EVE}
 
+A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. A \Gls{linux} alapokra épül, erre épülő operációs rendszerük neve az EVE-OS. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az EVE-OS jelenleg támogat Docker konténereket, virtuális gépeket és Kubernetes klasztereket, viszont utóbbi támogatása kezdetleges.
+
+A projekt tervezése során kiemelt figyelmet fordítottak a a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek az rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.
+
+Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszert képes egyszerre több backendhez csatlakozni egy időben. Ilyen backend lehet a felhőben vagy helyileg telepített. Egyszerre képes futtatni Kubernetes klaszterben lévő alkalmazásokat, virtuális gépeket és konténereket. 
+
+A különböző backendek támogatása azzal jár, hogy ezeket egységes absztrakt interfészen keresztül kell tudnia kezelnie. Ennek az lehet a hátránya, hogy az elérhető funkcionalitások között a legkisebb közös halmazt szolgálja ki a felhasználó számára. A konkrét platformok egyéni előnyeinek kiaknázásra nem sok lehetőséget ad.
+
+
 \subsection{Akarino Edge Stack}
 
+A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy specifikáció halmaz, amely igyekszik a peremhálózati rendszerek fejlesztése során gyakran felmerülő problémákra tervezési mintákat adni.
+
+Ezek a specifikációk lefednek számos az peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.
+
+% TODO befejezni
+
 \subsection{StarlingX}
 
+% TODO erről is írni valamit
+
 \subsection{KubeEdge}
 
 A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit peremhálózati rendszerek kezelésével\cite{kubeedge_docs}. Így lehetővé teszi a konténerizált alkalmazások futtatását a peremhálózaton. Architektúrája két részből épül fel, a központi felhőből és a peremhálózatól.
@@ -184,6 +201,25 @@ Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy
 
 Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével.
 
-\subsection{AWS IoT Greengrass}
+\subsection{\acrshort{aws} \acrshort{iot} Greengrass}
 
-\subsection{Azure IoT Edge}
+Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} egy az \textit{Amazon} által fejlesztett menedzselt (\acrshort{paas}) \acrshort{iot} platform. Segítségével a fejlesztés során lehetőség van az alkalmazáskomponensek helyi tesztelésére, valamint azok üzemeltetési folyamatainak felügyeletére is lehetőséget kínál. Az egyes telepített komponensek távoli frissítése is megoldott.
+
+A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó szolgáltatások halmaza, a másik pedig a peremhálózati rendszerre telepíthető\footnote{Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} támogatja azt a megközelítést is ahol a peremhálózat maga a végeszközök rendszere. Ennek megfelelően a "kliens" alkalmazást oda is lehet telepíteni.} (itt átjáróként hivatkozott) "kliens" szoftver. Az \acrshort{iot} eszközök ezen az átjárón futó szoftverrel kommunikálnak. Az itt futó peremhálózati szolgáltatások pedig az interneten keresztül kommunikálnak az \acrshort{aws} felhőben futtatott többi komponenssel.
+
+A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor azok a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
+
+A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet
+
+\subsection{Azure \acrshort{iot} Edge}
+
+Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen bemutatása csak a teljesebb kép bemutatását szolgálja.
+
+
+Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget az egyes eszközökön. 
+
+A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface} amely a rendszer távoli monitorozásáért és kezeléséért felel.
+
+A rendszer üzembe helyezéséhez az \acrshort{iot} eszközökön kizárólag az \textit{Azure \acrshort{iot} Edge} csomag telepítése szükséges. Az eszköz regisztrálása után központilag van lehetőség alkalmazásmodulok telepítésére.
+
+Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldásról van szó, viszont a belső működése a szolgáltatásnak zárt. Az árazás szintekbe van sorolva, az ingyenes szinten naponta csupán nyolcezer üzenetet lehet átvinni a \gls{felho}ben futó rendszer és a peremen\footnote{A dolgozat értelmezésében a végeszközök.} található eszközök között.

src/thesis.tex

@@ -2,8 +2,9 @@
 % !TeX encoding = UTF-8
 % !TeX program = xelatex
 
-%\documentclass[11pt,a4paper,oneside]{report}             % Single-side
+% Ezt nyomtatás előtt ne felejtsem el állítani majd:
-\documentclass[11pt,a4paper,twoside,openright]{report}  % Duplex
+\documentclass[11pt,a4paper,oneside]{report}             % Single-side
+%\documentclass[11pt,a4paper,twoside,openright]{report}  % Duplex
 
 \input{include/packages}
 
@@ -73,8 +74,8 @@
 \include{content/overview}
 \include{content/birbnetes_impl}
 \include{content/ursim_impl}
-\include{content/scheduling}
+%\include{content/scheduling}
-\include{content/measurements}
+%\include{content/measurements}
 \include{content/conclusion}