marcsello/marci-dipterv-latex
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

some work

Browse Source
This commit is contained in:
Pünkösd Marcell 2021-12-15 21:26:36 +01:00
parent 07e66186f2
commit 5d3112976d
6 changed files with 231 additions and 220 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

199
src/content/appendices.tex
View File

@ -22,9 +22,200 @@
\end{itemize}
\section{Precíz időszinkronizáció}
\label{append:timesync}
\section{Madárhang felismerő rendszer előzetes munka részletezése}
\label{appendix: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 ezen kártevőktől \cite{nk}.
% NTP és PTP
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 felhő szoftver számára. A projekt jól szemlélteti egy ilyen architektúra átültetésének kihívásait perem és felhő számítástechnikai rendszerre.
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 felhő architektúrára terveztük. Az \acrshort{iot} eszközök közvetlenül a felhő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 alacsony erőforrás igénye miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a felhő által nyújtott komolyabb számítási teljesítményt.
Az algoritmusok elméleti működéséről 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. Az eszköz egy későbbi változatának felépítés-blokkváza \aref{fig:birbox_hardware_blockschema}.\ ábrán látható.
\begin{figure}[h!]
\centering
\includegraphics[width=0.95\textwidth]{figures/birbox_hardware_blockschema}
\caption{A második reviziós \acrshort{iot} eszköz belső hardveres felépítésének blokkváza}
\label{fig:birbox_hardware_blockschema}
\end{figure}
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 eredeti változatából később készült egy revízió, aminek kapcsán kapott egy soros csatlakozót és egy USB port is kivezetésre került a különböző rádiós interfészek csatlakoztatásának megkönnyítésére. Az új tervek alapján pedig további két modell épült. Az eszközök megjelenésbeli különbségét \aref{fig:doboz-ng}.\ ábra mutatja be.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{figures/doboz_new}
\caption{A második reviziós \acrshort{iot} eszközök csatlakozókkal és hangerő vezérlővel ellátott hátlapja}
\label{fig:doboz-ng}
\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. Az eszköz áramellátása természetesen nem csak hálózati táplálásról oldható meg. A tervek közt szerepelt napelemes és akkumulátoros megoldás is, de ezek nekünk kívül estek a munkánk témájából. Az ajánlásunk az, hogy bármilyen más áramellátást kívülről a telepített tápcsatlakozón keresztül kerüljön csatlakoztatásra.
\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 három rétegre bontható. Operációs rendszerre, platform függő \textbf{platform-illesztőre} és platform független \textbf{üzleti logikára}. Az egyes rétegeket \aref{fig:birbox_software_blockdiagram}.\ ábra vázolja.
\begin{figure}[h!]
\centering
\includegraphics[width=0.80\textwidth]{figures/birbox_software_blockdiagram}
\caption{Az \acrshort{iot} hardveren futó szoftver rétegei az információs összefüggésekkel ábrázolva.}
\label{fig:birbox_software_blockdiagram}
\end{figure}
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 felhő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 \enquote{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 \enquote{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{Felhő rendszer}
A felhőrendszer architektúráját tekintve mikroszolgáltatásokból épül fel. 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 a fejlesztés során, 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 lehetséges, 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 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}
\begin{figure}[h!]
\centering
\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
\caption{A felhő szoftver architekturális felépítése}
\label{fig:architecture-redesigned}
\end{figure}
A rendszerhez készült két webes kezelőfelület is, ebből egyiket hallgatótársunk Kunkli Richárd fejlesztette. Az egyik felület -- amelyet mi készítettünk -- a rendszer belső működésébe enged betekintést és néhány paraméter egyszerű beállítására ad lehetőséget. A második, pedig inkább a rendszert használó felhasználók számára készült, itt többek közt a folyamatokat a szőlővidék térképén vizualizálva figyelhetjük meg.
\subsubsection{Implementált mikroszolgáltatások}
Az általunk tervezett és implementált mikroszolgáltatások működéséről és felelősségei a következőek:
\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 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 osztályokat (esetünkben madarakat) 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 \enquote{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 felhő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. A kapcsolat kezdeményezése a felhőből nem egyszerű, hiszen a fogyó \acrshort{ipv4} címek és az \acrshort{ipv6} hálózatok csekély adoptációja és az eszközök nagy száma miatt könnyen előfordulhat, hogy azok \acrfull{nat} mögül kapcsolódnak. Erre az esetre ezért egy olyan protokollt szerettünk volna használni, amelynél a kapcsolatot a végeszköz kezdeményezi a felhő felé, de az üzenetküldés mindkét irányban lehetséges. Erre a feladatra az \acrshort{mqtt} használtuk, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve. Az \acrshort{mqtt} egy perzisztens \acrshort{tcp} kapcsolatot épít fel egy bróker felé, majd a bróker gondoskodik róla, hogy bármelyik fél képes legyen üzenetet küldeni és azt a címzett biztosan megkapja.

195
src/content/birbnetes_impl.tex
View File

@ -4,203 +4,22 @@
\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 ezen kártevőktől \cite{nk}.
É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. % TODO
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.
% Van ez a birbnetes és tök jó példa erre a rendszerre
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 felhő szoftver számára. A projekt jól szemlélteti egy ilyen architektúra átültetésének kihívásait perem és felhő számítástechnikai rendszerre.
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 komponenseket vázolom.
\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 felhő architektúrára terveztük. Az \acrshort{iot} eszközök közvetlenül a felhő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 alacsony erőforrás igénye miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a felhő által nyújtott komolyabb számítási teljesítményt.
Az algoritmusok elméleti működéséről 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. Az eszköz egy későbbi változatának felépítés-blokkváza \aref{fig:birbox_hardware_blockschema}.\ ábrán látható.
\section{Felépítés}
\begin{figure}[h!]
\centering
\includegraphics[width=0.95\textwidth]{figures/birbox_hardware_blockschema}
\caption{A második reviziós \acrshort{iot} eszköz belső hardveres felépítésének blokkváza}
\label{fig:birbox_hardware_blockschema}
\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 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 eredeti változatából később készült egy revízió, aminek kapcsán kapott egy soros csatlakozót és egy USB port is kivezetésre került a különböző rádiós interfészek csatlakoztatásának megkönnyítésére. Az új tervek alapján pedig további két modell épült. Az eszközök megjelenésbeli különbségét \aref{fig:doboz-ng}.\ ábra mutatja be.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{figures/doboz_new}
\caption{A második reviziós \acrshort{iot} eszközök csatlakozókkal és hangerő vezérlővel ellátott hátlapja}
\label{fig:doboz-ng}
\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. Az eszköz áramellátása természetesen nem csak hálózati táplálásról oldható meg. A tervek közt szerepelt napelemes és akkumulátoros megoldás is, de ezek nekünk kívül estek a munkánk témájából. Az ajánlásunk az, hogy bármilyen más áramellátást kívülről a telepített tápcsatlakozón keresztül kerüljön csatlakoztatásra.
\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 három rétegre bontható. Operációs rendszerre, platform függő \textbf{platform-illesztőre} és platform független \textbf{üzleti logikára}. Az egyes rétegeket \aref{fig:birbox_software_blockdiagram}.\ ábra vázolja.
\begin{figure}[h!]
\centering
\includegraphics[width=0.80\textwidth]{figures/birbox_software_blockdiagram}
\caption{Az \acrshort{iot} hardveren futó szoftver rétegei az információs összefüggésekkel ábrázolva.}
\label{fig:birbox_software_blockdiagram}
\end{figure}
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 felhő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 \enquote{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 \enquote{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{Felhő rendszer}
A felhőrendszer architektúráját tekintve mikroszolgáltatásokból épül fel. 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 a fejlesztés során, 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 lehetséges, 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 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}
\begin{figure}[h!]
\centering
\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
\caption{A felhő szoftver architekturális felépítése}
\label{fig:architecture-redesigned}
\end{figure}
A rendszerhez készült két webes kezelőfelület is, ebből egyiket hallgatótársunk Kunkli Richárd fejlesztette. Az egyik felület -- amelyet mi készítettünk -- a rendszer belső működésébe enged betekintést és néhány paraméter egyszerű beállítására ad lehetőséget. A második, pedig inkább a rendszert használó felhasználók számára készült, itt többek közt a folyamatokat a szőlővidék térképén vizualizálva figyelhetjük meg.
\subsubsection{Implementált mikroszolgáltatások}
Az általunk tervezett és implementált mikroszolgáltatások működéséről és felelősségei a következőek:
\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 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 osztályokat (esetünkben madarakat) 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 \enquote{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 felhő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. A kapcsolat kezdeményezése a felhőből nem egyszerű, hiszen a fogyó \acrshort{ipv4} címek és az \acrshort{ipv6} hálózatok csekély adoptációja és az eszközök nagy száma miatt könnyen előfordulhat, hogy azok \acrfull{nat} mögül kapcsolódnak. Erre az esetre ezért egy olyan protokollt szerettünk volna használni, amelynél a kapcsolatot a végeszköz kezdeményezi a felhő felé, de az üzenetküldés mindkét irányban lehetséges. Erre a feladatra az \acrshort{mqtt} használtuk, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve. Az \acrshort{mqtt} egy perzisztens \acrshort{tcp} kapcsolatot épít fel egy bróker felé, majd a bróker gondoskodik róla, hogy bármelyik fél képes legyen üzenetet küldeni és azt a címzett biztosan megkapja.
\section{Felkészítés peremhálózati alkalmazásra}

2
src/content/introduction.tex
View File

@ -15,7 +15,7 @@ Munkám célja, hogy alapos áttekintést adjak a felhő és a peremhálózati s
\section{Fejezetek áttekintése}
Az első fejezet bemutatja a munkát és a kutatás hátterét.
Az első fejezet bemutatja a feladatot és a kutatás hátterét.
A második fejezetben részletesen bemutatom a felhő és peremhálózati számítástechnikát és az azt megvalósító keretrendszereket.

4
src/content/overview.tex
View File

@ -174,7 +174,7 @@ A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege): Ebben a rétegben található szolgáltatások felelnek a az információ külső szolgáltatásba való továbbításáért: a gyűjtött adatok feldolgozásáért átalakításáért és továbbküldéséért. Az itt elhelyezkedő szolgáltatások \enquote{funkcionális csővezetéket} valósítanak meg. Ami azt jelenti, hogy minden feldolgozandó adat egy folyamatot indít el, amelynek során az funkciókon keresztül jut el végül a küldésig.
\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege): A rétegben elhelyezkedő szolgáltatások feladata a többi eszközzel szenzorral való interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatások a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra alakítani.
\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege): A rétegben elhelyezkedő szolgáltatások feladata a többi eszköz és szenzor fölé, egyfajta interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatások a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra alakítani.
\end{itemize}
Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.
@ -246,6 +246,8 @@ A \textit{Kubernetes Federation} (Röviden \textit{Kubefed}) eredetileg a \texti
Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klaszter. Ez lesz az irányító klaszter (nagyjából olyan szerepe van mint a mester node-nak a klaszteren belül). Ehhez csatlakozik be a többi klaszter. Az egyes federált funkcionalitások megvalósítására egyedi \acrshort{api} objektumokat hoz létre. Ilyen objektumokkal tudjuk kezelni egységesen a multiklaszter erőforrásokat \cite{kubefed_userguide}.
Implementáció szempontjából a federáció vezérlőre telepít és futtat olyan szolgáltatásokat, amelyek hozzáférnek a \textit{Kubernetes} \acrshort{api} felületéhez, illetve a megfelelő proxykon keresztül a többi klaszter \acrshort{api} felületéhez is. Így képesek olvasni az ott meghatározott egyedi objektumokat és annak megfelelően a megfelelő klaszterekben natív objektumokat létrehozni.
Egy federált \textit{Kubernetes} környezetnek több felhasználása is lehet. De a felhasználási mintákban szinte alapvető, hogy az önálló klaszterek geológiailag elhatárolva üzemelnek \cite{kubernetes_why_federation}. Ez megfeleltethető annak, ahogy a peremhálózati rendszerek és a felhő rendszerek is különállóan üzemelnek.
Bár egyértelműen látszik, hogy a \textit{Kubefed} elsősorban nem a peremhálózati rendszerek által nyújtott elvárások kielégítésre lett kifejlesztve. Általános klaszter federációs megoldásként viszont képes arra, hogy az ezen a téren támasztott elvárásoknak is többszörösen megfeleljen.

51
src/content/ursim_impl.tex
View File

@ -10,23 +10,23 @@ A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszeku
Ez az alkalmazás a peremhálózati rendszerek alacsony késleltetését aknázza ki. Hiszen a robotika vezérlésnél fontos a precíz irányítás, úgy vélem itt különösen jól alkalmazható ez a technológia. A peremhálózati rendszereknek hála tovább csökkenthetővé válik a gyárakban helyben telepített informatikai infrastruktúra mértéke, hiszen több alkalmazás válik felhőbe \enquote{költöztethetővé} és ezáltal annak előnyeit is nagyobb mértékben lesznek képesek kihasználni a gyártósorok.
Ebben a feladatban egy már rendelkezésre álló demót alakítottam át úgy, hogy az kihasználja a peremhálózati rendszerek adta lehetőségeket.
Ebben a feladatban egy már rendelkezésre álló demonstrációt alakítottam át úgy, hogy az kihasználja a peremhálózati rendszerek adta lehetőségeket.
\section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése
A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demó szcenárió, amely kifejezetten a hálózati késleltetés jelentőségének bemutatására lett tervezve. Ez a szcenárió magában foglalja mind a szoftveres és a hardveres megoldást, a kettőt összekötő hálózatot és még egyedileg 3D nyomtatott munkadarabokat is.
A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demonstrációs szcenárió, amely kifejezetten a hálózati késleltetés jelentőségének bemutatására lett tervezve. Ez a szcenárió magában foglalja mind a szoftveres és a hardveres megoldást, a kettőt összekötő hálózatot és még egyedileg 3D nyomtatott munkadarabokat is.
\subsection{\textit{Universal Robots}}
A demóban használt robotkarokat az \textit{Universal Robots} nevű dán vállalat tervezi és gyártja. A gyártó palettáján több robotkar is megtalálható. Ez az írás idejében kétszer három plusz egy modellt jelent, az \textit{UR3} és \textit{UR3e}, az \textit{UR5} és \textit{UR5e}, az \textit{UR10} és \textit{UR10e} illetve az \textit{UR16e}. Mindegyik robotkar egyre növekvő módon egyre növekvő kihívásoknak képes eleget tenni. % TODO: Cite
A demonstráció használt robotkarokat az \textit{Universal Robots} nevű dán vállalat tervezi és gyártja. A gyártó palettáján több robotkar is megtalálható. Ez az írás idejében kétszer három plusz egy modellt jelent, az \textit{UR3} és \textit{UR3e}, az \textit{UR5} és \textit{UR5e}, az \textit{UR10} és \textit{UR10e} illetve az \textit{UR16e}. Mindegyik robotkar egyre növekvő módon egyre növekvő kihívásoknak képes eleget tenni. % TODO: Cite
Az \textit{Universal Robots} által gyártott robotkarok vezérlését a hozzákapcsolt \textit{Control Box} végzi. Ez lényegében egy Mini-ITX számítógép, ami egyéni \Gls{linux} alapú operációs rendszert futtat. Ezen a számítógépen fut a robotkarok alacsony szintű vezérlője, amelyet különböző hálózati protokollok segítéségével kezelhetünk, illetve a grafikus felület, amely lokális kapcsolaton csatlakozik ezekhez az interfészekhez \cite{urscriptreference}.
A demóhoz használt két robotkar típusa \textit{UR3} és \textit{UR3e}.
A demonstrációhoz használt két robotkar típusa \textit{UR3} és \textit{UR3e}.
\subsubsection{Fizikai jellemzők}
Jellemzően többfajta felépítésű robotkar létezik. A demó során használt mindkettő robotkar csuklós felépítésű, azaz az emberi karhoz hasonlóan hajlatokkal (joint) rendelkezik a merev tagok között.
Jellemzően többfajta felépítésű robotkar létezik. A demonstráció során használt mindkettő robotkar csuklós felépítésű, azaz az emberi karhoz hasonlóan hajlatokkal (joint) rendelkezik a merev tagok között.
A használt robotkarok hat darab ilyen hajlattal rendelkeznek, amely kellő szabadságot nyújt nekik a mozgás terén. A hat jointból ötöt +/- 360$^\circ$ lehet elforgatni, az utolsót, amely a robotkar \enquote{csuklóját} adja pedig végtelenszer lehet körbeforgatni. Egy ilyen robotkar képes fél méteres (500mm) körön belül mozgásokat végezni, és három kilogramm hasznos terhet mozgatni. Maga a robotkar saját súlya 11 kilogramm \cite{ur3_specs}.
@ -35,18 +35,17 @@ A két robotkar végére két különböző gripper van telepítve, mindkettő \
\subsubsection{Kommunikációs interfész}
Az demó által használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg \cite{robot_client_interfaces}:
Az demonstráción használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg \cite{robot_client_interfaces}:
\begin{itemize}
\item \textbf{Primary/Secondary Interfaces}: A robotok vezérlő szoftvere két interfészt tart fenn a robotkar státuszának módosítására és megfigyelésére. Az elsődleges (primary) interfészen olvasni és írni is lehet a robot állapotát a másodikon csak olvasni. Elsősorban ez az interfész a grafikus kezelőfelülettel történő kommunikációra lett kifejlesztve. URScript parancsokat képes küldeni és fogadni 10Hz-es rátával (Azaz 100ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt).
\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz 2ms gyakorisággal) \cite{robot_controll_tcpip}.
\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges és másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz 2ms gyakorisággal) \cite{robot_controll_tcpip}.
\item \textbf{Dashboard Server}: A robot grafikus kezelőfelületét is képesek vagyunk közvetlenül, programozottan vezérelni \acrshort{tcp} kapcsolaton keresztül. Ez olyan alapvető funkciókat enged végrehajtani, mint az eltárolt programok betöltése, futtatása, felhasználók hozzáférési szintjének szabályozása, és alapvető robot státusz információk lekérdezése.
\item \textbf{Socket Communication}: Ez egy alacsony szintű \acrshort{tcp} alapú kommunikáció, amelyben a robot kliensként viselkedik és a szerver, amihez kapcsolódik látja el utasításokkal. Természetesen ezen a protokollon is \textit{URScript} parancsokat adhatunk ki, ezekben segítő utasítások vannak a kapcsolat életciklusának kezelésére.
\item \textbf{\acrshort{xml}-\acrshort{rpc}}: Ez a protokol lehetőséget ad sokkal széles körűbb alkalmazásokra, mint az előbbiekben említett \textit{URScript}et használó protokollok. Hiszen az egyes funkcióit a robotoknak a paraméterekkel együtt függvényhívás szerűen végezhetjük. Ezzel sokkal komplexebb programok készíthetőek.
\item \textbf{\acrfull{rtde}}: Az \acrshort{rtde}-t egy robusztus megoldásnak tervezték, amely kiválthatja a \textit{Real-time} interfészt. Lehetővé teszi az \textit{UR} kontroller számára az egyéni státusz-adat és regiszter állapotok átvitelét. Ez az interfész valósidejű szinkronizációt tesz lehetővé akár 125Hz-es rátával (8ms/üzenet).
@ -67,30 +66,30 @@ A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást
\subsubsection{Szimulátor}
Természetesen a tanszéken csak kettő robotkar van, amelyek nem állnak mindig készen a tesztelésre. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a Demót összeállító csapat által. Végül a leghatékonyabban használhatónak a \textit{DockURSim}\footnote{\url{https://github.com/ahobsonsayers/DockURSim}} bizonyult.
A tanszéken található kettő robotkar természetesen nem áll mindig rendelkezésre. Más csapatok más-más projektekben is használják. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a projekten korábban dolgozó csapat által. Végül a leghatékonyabban használhatónak a \textit{DockURSim}\footnote{\url{https://github.com/ahobsonsayers/DockURSim}} bizonyult.
Lényegében a \textit{DockURSim} a robotkarokat közvetlenül irányító, \textit{Control Box}on futó szoftver becsomagolva egy \textit{Docker} konténerbe. Konkrét robotkart nem irányít, de a kommunikációs interfészeket és azok funkcionalitását teljes mértékben implementálja. Lehetőségünk van a beépített \acrfull{rdp} szerveren keresztül grafikus felületet\footnote{Ez a grafikus felület a \textit{Teach Pendant}on grafikusan kezelhető felület.} kezelni és ott meg tudjuk figyelni a robotkar mozgását.
Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy izolált környezetben tudja csak szimulálni, így a környezet fizikai hatásai, a gripperek működése és a robotkarok egymással való találkozását nem képes modellezni.
\subsection{Demó}
\subsection{Demonstráció}
A megvalósított demó egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemel egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi.
A megvalósított demonstráció egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemel egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi.
Bár egyszerűnek tűnik, ebben a szcenárióban nagy hangsúly helyezkedik a hálózat pontos időzítésérére. Hiszen a kritikus ponton, amikor a két robotkar össze illeszti a munkadarabot kiemelten fontos, hogy egyszerre mozogjanak, hiszen ha ez nem sikerül, akkor összeillesztés helyett eltörik a munkadarabot.
A következőkben részletesen bemutatom a demó felépítését és működését.
A következőkben részletesen bemutatom ennek a szoftvernek a felépítését és működését.
\subsubsection{Környezet}
A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. Két oldalt a két robotkar helyezkedik el. A robotkaroknak a szcenáriót tervező csapat az Erik és a Fred neveket adták. Az Erik nevezetű robotkaron található az \textit{rg2-ft} típusú gripper, amely önállóan csatlakozik a hálózatra, ezzel szemben a Fred nevezetű robotkaron lévő gripper a robotkar kommunikációs interfészén keresztül kapja az információt.
A demonstrációs szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. Két oldalt a két robotkar helyezkedik el. A robotkaroknak a szcenáriót tervező csapat az Erik és a Fred neveket adták. Az Erik nevezetű robotkaron található az \textit{rg2-ft} típusú gripper, amely önállóan csatlakozik a hálózatra, ezzel szemben a Fred nevezetű robotkaron lévő gripper a robotkar kommunikációs interfészén keresztül kapja az információt.
Az asztalon a két munkadarabnak kijelölt helye van, ahonnan a robotkarok felemelik, az összeillesztés az asztal közepénél történik, majd valahol itt is helyezi el a kész darabot. A környezet vizuális bemutatásául \aref{fig:work_table}.\ ábra szolgál.
\begin{figure}[h!]
\centering
\includegraphics[width=0.6\textwidth]{figures/work_table}
\caption{A demó környezet elemeit tartalmazó asztal alaprajza}
\caption{A demonstrációs környezet elemeit tartalmazó asztal vázlatos alaprajza}
\label{fig:work_table}
\end{figure}
@ -110,20 +109,20 @@ Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinát
\section{Felkészítés a peremhálózati alkalmazásra} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
Alapos tervezést igényelt a fenti monolit demó átültetése egy felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
Alapos tervezést igényelt a fenti monolit demonstráció átültetése felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
\subsection{Architektúra}
Mivel a \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{Kubefed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik.
Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demó vezérlést. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait.
Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demonstráció vezérlését. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait.
A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_services_plan-blocks}.\ ábra ad áttekintést. Érdemes megfigyelni, hogy végeredményében a három rétegű architektúránk egy három szintű robot vezérlést implementál, amely a vezérlési feladatokat egyre nagyobb absztrakcióval kezeli. Az egyes rétegeken belüli rendszerek tervezését a következő szekciókban ismertetem.
\begin{figure}[h!]
\centering
\includegraphics[width=0.9\textwidth]{figures/ursim_services_plan-blocks}
\caption{Demó vezérlés felbontása funkcionális egységekre a futtatási környezet és a késleltetés igények szerint}
\caption{Vezérlés felbontása funkcionális egységekre a futtatási környezet és a késleltetés igények szerint}
\label{fig:usrsim_services_plan-blocks}
\end{figure}
@ -152,12 +151,12 @@ Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data},
Az adatok gyűjtése nem késleltetés érzékeny, ezért nem okoz problémát, ha a peremhálózatról egyenesen a felhőbe küldjük. Mivel a dolgozatom a \textit{Big Data} konkrét elemzésére nem tér ki, ezért az általam tervezett rendszerben a mérési adatokkal való tervezés kimerül azok gyűjtésében.
\subsection{\textit{Single Robot Controller}} % Peremhálózati rendszer basically
\subsection{Peremhálózati szolgáltatások} % Peremhálózati rendszer basically
\label{sec:single_robot_contoller_plans}
\Aref{sec:edge_layer_plans}.\ szekcióban ismertetettek alapján terveztem meg a peremhálózati rendszerben futó mikroszolgáltatás halmazt. Jelenleg ez egyetlen egy mikroszolgáltatásból áll, ez az a szolgáltatás a \textit{program}ok futtatását valósítja meg.
Egy program egyszerre csak egy robotkar működését írja le, így egy ilyen komponens egyszerre csak egy robotkarhoz kapcsolódik. A demó végrehajtásához két komponensnek kell kapcsolódnia.
Egy program egyszerre csak egy robotkar működését írja le, így egy ilyen komponens egyszerre csak egy robotkarhoz kapcsolódik. A demonstráció végrehajtásához két komponensnek kell kapcsolódnia.
Emellett meg kell oldania olyan problémákat is, amelyek \aref{sec:ursim_demo_control}.\ szekcióban ismertetett programnál adottak -- vagy legalábbis közel-triviálisan megoldhatóak -- voltak.
@ -177,7 +176,7 @@ Egy \textit{plugin} által definiált utasítás a funkcionalitás mellett annak
\subsubsection{Szinkronizáció}
\label{sec:ursim_snyc_proto}
A demó során kiemelt szerepe van a két robotkar lépéseinek összehangolására kritikus pontokban.
A demonstráció során kiemelt szerepe van a két robotkar lépéseinek összehangolására kritikus pontokban.
Mivel itt már nem két szál összehangolásáról van szó hanem két egymástól független alkalmazásra, amelyek az architektúra, a peremhálózati keretrendszer és a futtatási környezetből adódóan jóformán csak hálózaton tudnak kommunikálni, ezért ez egy teljesen más megoldást kívánt.
@ -227,7 +226,7 @@ A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrs
Az architektúra, melyet \aref{sec:edge_layer_plans}.\ szekcióban bemutattam lehetővé teszi, hogy a felhőben futó komponensek bármilyen programot adjanak a peremhálózati réteg számára, legyen az automatikusan vagy részben automatikusan generált.
Mivel sem a demó, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
Mivel sem a demonstráció, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
A szolgáltatásba fel lehet tölteni a felhasználó által megírt programot, illetve le lehet tölteni onnan egy egyszerű \acrshort{rest} \acrshort{api} használatával.
@ -240,12 +239,12 @@ Mivel a programok előre definiált formában léteznek, ezért kell egy kompone
Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől és futtató környezettől. Az alapvető feladata az, hogy szükség esetén egy absztrakcióval szolgáljon a konkrét programfuttatási eljárás fölé egyszerű \acrshort{rest} \acrshort{api} kiszolgálásával.
\subsubsection{\textit{Metrics Service}}
%\subsubsection{\textit{Metrics Service}}
% TODO: Ez mekkora kamu
% A metrika gyűjtés tervezése és implementációja még hátra van.
A metrika gyűjtésének folyamatát a diplomatervezés második felében fogom megtervezni és megvalósítani.
%A metrika gyűjtésének folyamatát a diplomatervezés második felében fogom megtervezni és megvalósítani.
\section{Implementáció}
@ -327,7 +326,7 @@ A \textit{plugin} által megvalósított egyetlen utasítás addig várakoztatja
Ez a \textit{plugin} regisztrál egy endpointot a \acrshort{http} \acrshort{api}-ban, amellyel a program végrehajtása folytatható.
Ennek a pluginnek a használatával megvalósítható, a demóban is alkalmazott \textit{jogging} módú futtatás. A léptetés itt nem billentyűlenyomással, hanem az \acrshort{api} meghívásával történik.
Ennek a pluginnek a használatával megvalósítható, a demonstráció során is alkalmazott \textit{jogging} módú futtatás. A léptetés itt nem billentyűlenyomással, hanem az \acrshort{api} meghívásával történik.
\subsubsection{Egyebek}
@ -341,7 +340,7 @@ A fent vázolt \textit{plugin}ek mellett készítettem néhány egyszerűbbet is
\subsection{\textit{Program} formátum}
A \textit{Program}ok felépítése és struktúrája egyszerű. Úgy alkottam meg, hogy mind ember által könnyen értelmezhető és szerkeszthető legyen, de könnyen értelmezhető legyen program által is.
A robotkarok vezérlésének lépései az általam tervezett formátumú \textit{programokban} vannak összegyűjtve. A \textit{Programok} felépítése és struktúrája egyszerű. Tervezés során figyelembe vettem, hogy mind ember által könnyen értelmezhető és szerkeszthető legyen, de könnyen feldolgozható is legyen szoftver által is.
A \textit{program} leírása tartalmazza első sorban annak verzióját. Ez a későbbi kompatibilitási problémák megoldásának egyszerűsítésére lett bevezetve, jelenleg csak az \texttt{1}-es verzió létezik. Az a program, ahol ennek a mezőnek az értéke nem \texttt{1} az érvénytelen.
@ -381,7 +380,7 @@ program:
A program sémájának validálására a \textit{Marshmallow}\footnote{\url{https://github.com/marshmallow-code/marshmallow}} könyvtárat használtam. Ezzel deklaratív módon tudtam validációs sémákat írni, amelyet minden komponensnél használtam, amely érintkezik valamilyen szinten \textit{program}okkal. Így a lehető leghamarabb vissza tudja utasítani a rendszer a hibás programokat.
Az eredeti demó mozgását futás időben fordítottam le az általam definiált \textit{program} struktúrára azáltal, hogy a demó programban a \gls{python} által biztosított reflexiókat használva, az egyes lépéseket lecseréltem arra, hogy fájlba mentse a az utasításokat és a paramétereiket.
Az eredeti szoftver által vezérelt mozgást futás időben fordítottam le az általam definiált \textit{program} struktúrára azáltal, hogy a program kódjában a \gls{python} által biztosított reflexiókat használva, az egyes lépéseket lecseréltem fájlba mentő funkciókra amely rögzíti az utasításokat és a paramétereiket.
%\section{Tesztelés}

BIN
src/figures/nagyon_simple_birbnetes.pdf Normal file
View File

Binary file not shown.