Implemented Markosz feedback
This commit is contained in:
parent
a3eb99693a
commit
b5cdf8cfe6
@ -27,17 +27,17 @@
|
|||||||
|
|
||||||
É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 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}.
|
||||||
|
|
||||||
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.
|
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 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.
|
||||||
|
|
||||||
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 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.
|
A fejlesztett rendszert 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}
|
\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 hangminták felismerése 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 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.
|
||||||
|
|
||||||
@ -57,7 +57,7 @@ Működésének alapját az adja, hogy úgy próbálja az adathalmazt felosztani
|
|||||||
\subsubsection{Konvolúciós Neurális Hálók}
|
\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 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. 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}.
|
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}.
|
||||||
|
|
||||||
@ -69,7 +69,7 @@ A termőföldre telepített eszközök alacsony áramfogyasztású és következ
|
|||||||
|
|
||||||
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.
|
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.
|
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}
|
\subsubsection{Hardver}
|
||||||
|
|
||||||
@ -83,9 +83,9 @@ A hardver lényegében egy számítógép a szükséges perifériákkal együtt
|
|||||||
\end{figure}
|
\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.
|
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öztünk volna. Terveink szerint, a kész rendszer esetén konkrét mérésekre és számításokra alapozzuk a hardverválasztást, de a fejlesztés során ne legyen teljesítméynbeli 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 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 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.
|
||||||
|
|
||||||
@ -113,7 +113,11 @@ Az eszköz eredeti változatából később készült egy revízió, aminek kapc
|
|||||||
\label{fig:doboz-ng}
|
\label{fig:doboz-ng}
|
||||||
\end{figure}
|
\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.
|
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.
|
||||||
|
túlmutattak a kitűzött célokon.
|
||||||
|
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}
|
\subsubsection{Szoftver}
|
||||||
@ -129,9 +133,9 @@ Az erre telepített szoftver komponens három rétegre bontható. Operációs re
|
|||||||
\label{fig:birbox_software_blockdiagram}
|
\label{fig:birbox_software_blockdiagram}
|
||||||
\end{figure}
|
\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.
|
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.
|
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ázisnak, 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.
|
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.
|
||||||
|
|
||||||
@ -141,14 +145,13 @@ A szoftver \gls{python} nyelven került implementálásra. A telepítése közve
|
|||||||
|
|
||||||
\subsection{Felhő rendszer}
|
\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 felhő rendszerben futó szoftver 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 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
|
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.
|
||||||
á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.
|
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 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.
|
||||||
|
|
||||||
@ -173,7 +176,7 @@ A rendszerhez készült két webes kezelőfelület is, ebből egyiket hallgatót
|
|||||||
|
|
||||||
\subsubsection{Implementált mikroszolgáltatások}
|
\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:
|
Az általunk tervezett és implementált mikroszolgáltatások működése és felelősségei a következőek:
|
||||||
\begin{itemize}
|
\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{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.
|
||||||
|
|
||||||
|
|||||||
@ -7,21 +7,21 @@ Az utóbbi években a felhő alapú alkalmazás üzemeltetés töretlen népszer
|
|||||||
|
|
||||||
A felhő alapú rendszerek jövője szinte biztosított. De vannak olyan alkalmazási területek, ahova bizonyos limitációi miatt eddig nem sikerült betörnie. Az alacsony késleltetés és nagy mennyiségű adatok átvitele idáig sarkalatos pontja volt a felhő adoptációs törekvéseknek.
|
A felhő alapú rendszerek jövője szinte biztosított. De vannak olyan alkalmazási területek, ahova bizonyos limitációi miatt eddig nem sikerült betörnie. Az alacsony késleltetés és nagy mennyiségű adatok átvitele idáig sarkalatos pontja volt a felhő adoptációs törekvéseknek.
|
||||||
|
|
||||||
Ezekre a problémákra adhat megoldást ha a felhőt kiterjesztjük az eddig megszokott adatközpontokon túl egyenesen a peremhálózatokig. Ezzel közelebb hozva azt a végeszközökig. Így az eddig nehezen adoptálható alkalmazások is hasznát vehetik a felhőszolgáltatások számtalan előnyének. Kutatások szerint alig 5 éven belül az adatfeldolgozás csaknem 75\%-a már nem tradicionális adatközpontokban fog történni \cite{gartner}.
|
Ezekre a problémákra adhat megoldást, ha a felhőt kiterjesztjük az eddig megszokott adatközpontokon túl egyenesen a peremhálózatokig, ezzel közelebb hozva azt a végeszközökig. Így az eddig nehezen adoptálható alkalmazások is hasznát vehetik a felhőszolgáltatások számtalan előnyének. Kutatások szerint alig 5 éven belül az adatfeldolgozás csaknem 75\%-a már nem tradicionális adatközpontokban fog történni \cite{gartner}.
|
||||||
|
|
||||||
\section{A dolgozat célja}
|
\section{A dolgozat célja}
|
||||||
|
|
||||||
Munkám célja, hogy alapos áttekintést adjak a felhő és a peremhálózati számítástechnika jelenlegi állapotáról. Annak alkalmazásának előnyeiről és kihívásairól. Munkámat szeretném konkrét alkalmazásokkal és mérésekkel alátámasztani.
|
Munkám célja, hogy alapos áttekintést adjak a felhő és a peremhálózati számítástechnika jelenlegi állapotáról, alkalmazásának előnyeiről és kihívásairól. Munkámat konkrét alkalmazások segítségével mutatom be és eredményeimet mérésekkel fogom alátámasztani.
|
||||||
|
|
||||||
\section{Fejezetek áttekintése}
|
\section{Fejezetek áttekintése}
|
||||||
|
|
||||||
Az első fejezet bemutatja a feladatot é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.
|
A második fejezetben részletesen bemutatom a felhő és a peremhálózati számítástechnikát és az azt megvalósító keretrendszereket.
|
||||||
|
|
||||||
A harmadik fejezetben egy korábbi felhő és \acrshort{iot} alapú projektet mutat be amely a szőlővidékek kártevővédelmére lett kifejlesztve. Emellett megvizsgálja a peremhálózati rendszerek alkalmazásának lehetőségét.
|
A harmadik fejezet egy korábbi felhő és \acrshort{iot} alapú projektet mutat be, amely a szőlővidékek kártevővédelmére lett kifejlesztve. Emellett megvizsgálja a peremhálózati rendszerek alkalmazásának lehetőségét.
|
||||||
|
|
||||||
A negyedik fejezet egy gyártósori szcenáriót mutat be, ahol szintén körbejárja a peremhálózati rendszerek alkalmazásának lehetőségét. Majd bemutatja az átalakítás tervezési és implementálási folyamatát.
|
A negyedik fejezet egy gyártósori szcenáriót mutat be, ahol szintén körbejárja a peremhálózati rendszerek alkalmazásának lehetőségét, majd bemutatja az átalakítás tervezési és implementálási folyamatát.
|
||||||
|
|
||||||
Az ötödik fejezet a végeszközöket kiszolgáló komponensek dinamikus mozgatásával foglalkozik a felhő adatközpont és a peremhálózati rendszerek között.
|
Az ötödik fejezet a végeszközöket kiszolgáló komponensek dinamikus mozgatásával foglalkozik a felhő adatközpont és a peremhálózati rendszerek között.
|
||||||
|
|
||||||
|
|||||||
@ -26,10 +26,10 @@ Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a fel
|
|||||||
|
|
||||||
Amellett, hogy a felhőszolgáltatások adaptációja növekvő tendenciát mutat, az internetre kapcsolt eszközök száma is szépen gyarapodik \cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása \cite{iotadpotation}.
|
Amellett, hogy a felhőszolgáltatások adaptációja növekvő tendenciát mutat, az internetre kapcsolt eszközök száma is szépen gyarapodik \cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása \cite{iotadpotation}.
|
||||||
|
|
||||||
Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek \cite{stateofart}.
|
Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélesség tekintetében egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek \cite{stateofart}.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Felhős alkalmazásüzemeltetési eszközök}
|
\subsection{Felhő alapú alkalmazásüzemeltetési eszközök}
|
||||||
|
|
||||||
\subsubsection{Alkalmazás Konténer}
|
\subsubsection{Alkalmazás Konténer}
|
||||||
|
|
||||||
@ -38,45 +38,46 @@ Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalm
|
|||||||
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
|
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
|
||||||
|
|
||||||
% TODO: Átírni OCI-re
|
% TODO: Átírni OCI-re
|
||||||
\textit{Docker} használatakor, az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Kezdetben ez a képfájl formátum \textit{Docker} projekt által tervezett saját formátum volt. Később erre alapozva jött létre az \acrfull{oci} által készített \textit{Image Format Specification} (képfájl formátum specifikáció) amely a manapság használt szinte minden kontér futtató környezet támogat \cite{oci_format_docs}. Ennek köszönhetően a \textit{Docker} környezetben épített képfájlok használhatóak más alternatíváknál is, mint a \textit{Podman} \cite{podman_docs}.
|
\textit{Docker} használatakor az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Kezdetben ez a képfájl formátum a \textit{Docker} projekt által tervezett saját formátum volt. Később erre alapozva jött létre az \acrfull{oci} által készített \textit{Image Format Specification} (képfájl formátum specifikáció), amelyet a manapság használt szinte minden kontér futtató környezet támogat \cite{oci_format_docs}. Ennek köszönhetően a \textit{Docker} környezetben épített képfájlok használhatóak más alternatíváknál is, mint példáula \textit{Podman} \cite{podman_docs}.
|
||||||
|
|
||||||
Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Építése során a kívánt szoftver komponenseket (lefordított bináris, scriptek program fájlok, könyvtárak stb.) egy kiinduló képfájlba másoljuk bele. Ez a kiinduló képfájl lehet egy üres környezet, de lehet valamilyen operációs rendszer disztribúció felhasználói módú program környezete. Olyan képfájlok is léteznek, amelyekbe egy adott futtatókörnyezet már előre van telepítve, így csak a kész programunkat kell a megfelelő helyre tenni. Futtatáskor a konténer futtató környezet ezeket a képfájlokat használja fel a konténer fájlrendszerének felépítéséhez, a benne található alkalmazás futtatásához \cite{docker_docs}.
|
Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépek képfájlaihoz képest kisebb méretűek. Építése során a kívánt szoftver komponenseket (lefordított bináris, scriptek program fájlok, könyvtárak stb.) egy kiinduló képfájlba másoljuk bele. Ez a kiinduló képfájl lehet egy üres környezet, de lehet valamilyen operációs rendszer disztribúció felhasználói módú program környezete. Olyan képfájlok is léteznek, amelyekbe egy adott futtatókörnyezet már előre telepítve van, így csak a kész programunkat kell a megfelelő helyre tenni. Futtatáskor a konténer futtató környezet ezeket a képfájlokat használja fel a konténer fájlrendszerének felépítéséhez, a benne található alkalmazás futtatásához \cite{docker_docs}.
|
||||||
|
|
||||||
\subsubsection{Kubernetes}
|
\subsubsection{Kubernetes}
|
||||||
|
|
||||||
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások \cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.
|
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások \cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő platfrom a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát multihoszt környezetben.
|
||||||
|
|
||||||
|
|
||||||
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával \cite{kubernetes_docs}.
|
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával \cite{kubernetes_docs}.
|
||||||
|
|
||||||
Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
|
Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
|
||||||
|
|
||||||
A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért.
|
A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szerepek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért.
|
||||||
|
|
||||||
A klaszterünk felügyelete és kezelése az általa kiszolgált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával történik. Ezt az interfészt elérhetik a klaszterben futó szoftverek, de akár a klaszteren kívüli alkalmazások és azokon keresztül pedig az klaszter adminisztrátorai.
|
A klaszterünk felügyelete és kezelése az általa kiszolgált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával történik. Ezt az interfészt elérhetik a klaszterben futó szoftverek, de akár a klaszteren kívüli alkalmazások és azokon keresztül pedig a klaszter adminisztrátorai.
|
||||||
|
|
||||||
Egy \textit{Kubernetes} környezetben, az \acrshort{api}-n keresztül különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezeket az objektumokat a \textit{Kubernetes} dekleratív módon kezeli. Azaz az objektumok segítségével egy állapotot írhatunk le, amely a klaszter elvárt állapotát jelképezi. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani.
|
Egy \textit{Kubernetes} környezetben, az \acrshort{api}-n keresztül különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezeket az objektumokat a \textit{Kubernetes} dekleratív módon kezeli. Azaz, az objektumok segítségével egy állapotot írhatunk le, amely a klaszter elvárt állapotát határozza meg. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani.
|
||||||
|
|
||||||
Ezek az objektumok közül a legegyszerűbb példa a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos erőforrás névtereken, ilyen a hálózati vagy a folyamatok névtere. Azaz az egy \textit{Pod}-on belül futó két konténer a megfelelő rendszerhívásokkal tájékozódhat a másik konténerben futó folyamatok létezéséről. Illetve a hálózati kommunikációs erőforrásokat közösen használják.
|
Ezek az objektumok közül a legegyszerűbb példa a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos erőforrás névtereken, ilyen a hálózati vagy a folyamatok névtere. Azaz, az egy \textit{Pod}-on belül futó két konténer a megfelelő rendszerhívásokkal tájékozódhat a másik konténerben futó folyamatok létezéséről, illetve a hálózati kommunikációs erőforrásokat közösen használják.
|
||||||
|
|
||||||
A \textit{Podok} életciklusának (létrehozás, törlés) kezelésére a \textit{Deployment} objektum nyújt megoldást. A \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. Milyen \textit{Podból} és mennyi példánynak kell futnia.
|
A \textit{Podok} életciklusának (létrehozás, törlés) kezelésére a \textit{Deployment} objektum nyújt megoldást. A \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le: milyen \textit{Podból} mennyi példánynak kell futnia.
|
||||||
|
|
||||||
|
Ezek mellett még rengeteg alkalmazás specifikus objektumot kezel a \textit{Kubernetes}. Sőt, mindemellett lehetőség van arra, hogy egyedi erőforrás objektumokat is definiáljunk, amelyekkel könnyedén bővíthetjük a klaszterünk funkcionalitását.
|
||||||
|
|
||||||
Ezek mellett még rengeteg alkalmazás specifikus objektumot ad rendelkezésünkre a \textit{Kubernetes}. Sőt, mindemellett lehetőség van arra, hogy egyedi erőforrás objektumokat is definiáljunk. Amelyekkel könnyedén bővíthetjük a klaszterünk funkcionalitását.
|
|
||||||
|
|
||||||
\subsubsection{Mikroszolgáltatások}
|
\subsubsection{Mikroszolgáltatások}
|
||||||
|
|
||||||
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált \acrshort{api} használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
|
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált \acrshort{api} használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető.
|
||||||
|
|
||||||
Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
|
Az egységek fejlesztése és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
|
||||||
|
|
||||||
Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
|
Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
|
||||||
|
|
||||||
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár az alkalmazott programnyelv tekintetében is.
|
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell, az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár az alkalmazott programnyelv tekintetében is.
|
||||||
|
|
||||||
|
|
||||||
\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
|
\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
|
||||||
\label{sec:peremhalozati_rendszerek}
|
\label{sec:peremhalozati_rendszerek}
|
||||||
|
|
||||||
A felhő-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhőszolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
A felhő számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhő szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
||||||
|
|
||||||
\begin{figure}[h!]
|
\begin{figure}[h!]
|
||||||
\centering
|
\centering
|
||||||
@ -91,21 +92,21 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
|
|||||||
|
|
||||||
\subsection{Használt fogalmak}
|
\subsection{Használt fogalmak}
|
||||||
|
|
||||||
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés \cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások \cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így \cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik \cite{cb_whatisedge, dataplace_whatisedge}
|
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott, mivel nem is egy egyszerű kérdés \cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások \cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így \cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt beleértik \cite{cb_whatisedge, dataplace_whatisedge}.
|
||||||
|
|
||||||
A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre \enquote{\textit{Open Glossary of Edge Computing}} néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja \cite{openglossary}.
|
A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre \enquote{\textit{Open Glossary of Edge Computing}} néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja \cite{openglossary}.
|
||||||
|
|
||||||
A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
|
A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item \textbf{Cloud Computing} (felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
|
\item \textbf{Cloud Computing} (Felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot, tárolást és számítási kapacitást, tipikusan kevés számú, de nagy méretű regionális \gls{adatkozpont}okat használva.
|
||||||
|
|
||||||
\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végpontjaiba, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
|
\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása a hálózat logikai végpontjaiba, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a nyújtott alkalmazásoknak és szolgáltatásoknak. [\dots]
|
||||||
|
|
||||||
\item \textbf{Edge Cloud} (Perem felhő): felhő-szerű képességek az infrastruktúra peremén, amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhőként hivatkoznak rá.
|
\item \textbf{Edge Cloud} (Perem felhő): felhő-szerű képességek az infrastruktúra peremén, amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhőként hivatkoznak rá.
|
||||||
|
|
||||||
\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
|
\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
|
||||||
|
|
||||||
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen, tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek és lehetővé teszik a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja, de mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
||||||
|
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
@ -115,7 +116,7 @@ A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb
|
|||||||
|
|
||||||
Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a felhő és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve \enquote{közel} áll a \gls{vegeszkoz}höz.
|
Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a felhő és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve \enquote{közel} áll a \gls{vegeszkoz}höz.
|
||||||
|
|
||||||
Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
|
Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp, egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
|
||||||
|
|
||||||
\begin{figure}[h!]
|
\begin{figure}[h!]
|
||||||
\centering
|
\centering
|
||||||
@ -124,9 +125,9 @@ Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelye
|
|||||||
\label{fig:overview_with_edge}
|
\label{fig:overview_with_edge}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak \cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.
|
Az egyik ilyen jelentős előny a késeltetés csökkentése. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mindaz, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak \cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük, jelentős javulást tudunk elérni a késleltetésben.
|
||||||
|
|
||||||
Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek \cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
|
Az adatforgalomért sok esetben az internet szolgáltatók között is fizetniük kell az egyes feleknek \cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia, jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
|
||||||
|
|
||||||
% TODO: privacy
|
% TODO: privacy
|
||||||
|
|
||||||
@ -136,16 +137,16 @@ Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetni
|
|||||||
|
|
||||||
\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
||||||
|
|
||||||
Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.
|
Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve, szimbiózisban tudnak igazán érvényesülni.
|
||||||
|
|
||||||
% Itt le kell írni hogy van ez a két dolog
|
% Itt le kell írni hogy van ez a két dolog
|
||||||
Egy ilyen \enquote{szimbiózisban} a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk \cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek, kiegészítik a felhős alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
|
Egy ilyen \enquote{szimbiózisban} a peremhálózati rendszerekre, mint a felhő alapú szolgáltatások kiterjesztéseként tekinthetünk \cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek, kiegészítik a felhő alapú alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
|
||||||
|
|
||||||
A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi felhőből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében adnak értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
|
A gyakorlatban a technológia adott arra, hogy szinte bármit kiszervezzünk a központi felhőből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében adnak értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
|
||||||
|
|
||||||
|
|
||||||
\section{Gyakorlati alkalmazás}
|
\section{Gyakorlati alkalmazás}
|
||||||
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban.
|
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javulást lehet elérni a fenti szempontokban.
|
||||||
|
|
||||||
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek \cite{liu2019edge}, ipari rendszerek távfelügyelete \cite{hao2020cloud}, betegfelügyelet \cite{wang2020secure}, felhő alapú játék szolgáltatások \cite{edge_gaming}, okos otthonok és városok \cite{shi2016edge} és még sok minden más területen \cite{edge_companies}.
|
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek \cite{liu2019edge}, ipari rendszerek távfelügyelete \cite{hao2020cloud}, betegfelügyelet \cite{wang2020secure}, felhő alapú játék szolgáltatások \cite{edge_gaming}, okos otthonok és városok \cite{shi2016edge} és még sok minden más területen \cite{edge_companies}.
|
||||||
|
|
||||||
@ -154,9 +155,9 @@ A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a p
|
|||||||
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
|
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
|
||||||
\label{sec:frameworks}
|
\label{sec:frameworks}
|
||||||
|
|
||||||
Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati környezetben futtatni érdemes egy már létező keretrendszert használni. Az ilyen keretrendszerek nagyban megkönnyítik a fejlesztést, hiszen az adott alkalmazási terület általánosan felmerülő problémáit és kérdéseit megoldja. Így az alkalmazás fejlesztőinek nem szükséges azzal foglalkozni, hogy pontosan hogy indul el az alkalmazásuk egyik vagy másik helyen, mert ezt elfedi előlük a keretrendszer.
|
Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati környezetben futtatni, érdemes egy már létező keretrendszert használni. Az ilyen keretrendszerek nagyban megkönnyítik a fejlesztést, hiszen az adott alkalmazási terület általánosan felmerülő problémáit és kérdéseit megoldják. Így az alkalmazás fejlesztőinek nem szükséges azzal foglalkozni, hogy pontosan hogy indul el az alkalmazásuk egyik vagy másik helyen, mert ezt elfedi előlük a keretrendszer.
|
||||||
|
|
||||||
Egy ilyen keretrendszernél szükség van arra, hogy lehetőséget biztosítson egyes alkalmazás komponenseket a peremhálózati adatközpontban futtatni, másokat pedig a központi felhőben. Biztosítson valamilyen beavatkozható logikát arra, hogy egy alkalmazás mely adatközpontban kerül futtatásra. Elfedje az egyes futtató adatközpontok sajátosságait.
|
Egy ilyen keretrendszernél szükség van arra, hogy lehetőséget biztosítson egyes alkalmazás komponenseket a peremhálózati adatközpontban futtatni, másokat pedig a központi felhőben. Biztosítson valamilyen beavatkozható logikát arra, hogy egy alkalmazás mely adatközpontban kerül futtatásra és fedje el az egyes futtató adatközpontok sajátosságait.
|
||||||
|
|
||||||
A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:dynamic_scheduling}.\ fejezetben fejtem ki.
|
A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:dynamic_scheduling}.\ fejezetben fejtem ki.
|
||||||
|
|
||||||
@ -164,17 +165,17 @@ A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, e
|
|||||||
|
|
||||||
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
|
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
|
||||||
|
|
||||||
A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy akár az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.
|
A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.
|
||||||
|
|
||||||
A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
|
A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item \textit{Core Services Layer} (Központi szolgáltatások rétege): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért illetve a konfiguráció kezeléséért.
|
\item \textit{Core Services Layer} (Központi szolgáltatások rétege): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért, illetve a konfiguráció kezeléséért.
|
||||||
|
|
||||||
\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
|
\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira, hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
|
||||||
|
|
||||||
\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{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ö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.
|
\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ásoknak a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra.
|
||||||
\end{itemize}
|
\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.
|
Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.
|
||||||
@ -185,9 +186,9 @@ Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a
|
|||||||
|
|
||||||
A \textit{Project EVE} célja egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása erősen kezdetleges.
|
A \textit{Project EVE} célja egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása erősen 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.
|
A projekt tervezése során kiemelt figyelmet fordítottak a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben arra, 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 a 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.
|
Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszer 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.
|
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.
|
||||||
|
|
||||||
@ -199,7 +200,7 @@ A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy spec
|
|||||||
|
|
||||||
Ezek a specifikációk lefednek számos, a 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.
|
Ezek a specifikációk lefednek számos, a 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.
|
||||||
|
|
||||||
Lévén ezek csak specifikációk és tervrajzok. Az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok közül és ezeket ingyenesen elérthetjük.
|
Lévén ezek csak specifikációk és tervrajzok, az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok között és ezeket ingyenesen elérthetjük.
|
||||||
|
|
||||||
% TODO Majd megemlíteni, hogy ezt is megnéztem esküTM
|
% TODO Majd megemlíteni, hogy ezt is megnéztem esküTM
|
||||||
|
|
||||||
@ -207,7 +208,7 @@ Lévén ezek csak specifikációk és tervrajzok. Az egyes kiadások nem szoftve
|
|||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.
|
A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani, hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.
|
||||||
|
|
||||||
A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel.
|
A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel.
|
||||||
|
|
||||||
@ -223,16 +224,15 @@ A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó s
|
|||||||
|
|
||||||
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 a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
|
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 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
|
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}
|
\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.
|
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 leírás 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 ad egyes eszközökön.
|
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 ad 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 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.
|
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.
|
||||||
|
|
||||||
@ -242,17 +242,18 @@ Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldá
|
|||||||
\subsection{Kubernetes Federation}
|
\subsection{Kubernetes Federation}
|
||||||
% Nem erre való, de jó erre
|
% Nem erre való, de jó erre
|
||||||
|
|
||||||
A \textit{Kubernetes Federation} (Röviden \textit{Kubefed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon. Ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}.
|
A \textit{Kubernetes Federation} (Röviden \textit{Kubefed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon, ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}.
|
||||||
|
|
||||||
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}.
|
Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klasztert. 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.
|
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.
|
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 földrajzilag 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.
|
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 megfelel.
|
||||||
|
|
||||||
|
Népszerűségének köszönhetően sok dokumentáció, leírás és egyéb segítség létezik hozzá. Emellett erősen épít a \textit{Kubernetes} szolgáltatásaira és tervezési mintáira. Ezeknek köszönhetően az üzemeltetése viszonylag egyszerű a \textit{Kubernetes} klaszterek terén jártas üzemeltetők számára.
|
||||||
|
|
||||||
Népszerűségének köszönhetően sok dokumentáció, leírás és egyéb segítség létezik hozzá. Emellett erősen épít a \textit{Kubernetes} szolgáltatásaira és tervezési mintáira. Ezeknek köszönhetően az üzemeltetése viszonylag egyszerű az olyan illetők számára aki már jártas a \textit{Kubernetes} klaszterek terén.
|
|
||||||
|
|
||||||
% TODO: Még lehetne írni jókat erről
|
% TODO: Még lehetne írni jókat erről
|
||||||
|
|
||||||
|
|||||||
@ -4,23 +4,23 @@
|
|||||||
\label{chapter:ursim}
|
\label{chapter:ursim}
|
||||||
%----------------------------------------------------------------------------
|
%----------------------------------------------------------------------------
|
||||||
|
|
||||||
A negyedik ipari forradalom az \enquote{okos} gyártásról szól. A korábban helyileg telepített számítási erőforrásokat felhasználó előre meghatározott, kötött gyártás irányítást leváltja a felhő alapú folyamat irányítás és optimalizálás. Itt már nem csak a gyártás a lényeg, a folyamatok elemzésével és mély megértésével a hangsúly a precíz optimalizációra és produktivitás növelésre hegyeződik ki. Ehhez felhasználják az ipar legújabb vívmányait: Egyre nagyobb teret hódít a gyártástechnikában az Ipari \acrshort{iot} (\acrshort{iiot}), a mesterséges intelligencia és gépi tanulás, a gép-gép kommunikáció, valósidejű adatgyűjtés, \textit{Big Data} és még sok minden más \cite{whatisindustry4}.
|
A negyedik ipari forradalom az \enquote{okos} gyártásról szól. A korábban helyileg telepített számítási erőforrásokat felhasználó, előre meghatározott, kötött gyártás irányítást felváltja a felhő alapú folyamat irányítás és optimalizálás. Itt már nem csak a gyártás a lényeg, a folyamatok elemzésével és mély megértésével a hangsúly a precíz optimalizációra és a produktivitás növelésre hegyeződik ki. Ehhez felhasználják az ipar legújabb vívmányait: Egyre nagyobb teret hódít a gyártástechnikában az Ipari \acrshort{iot} (\acrshort{iiot}), a mesterséges intelligencia és gépi tanulás, a gép-gép kommunikáció, valósidejű adatgyűjtés, \textit{Big Data} és még sok minden más \cite{whatisindustry4}.
|
||||||
|
|
||||||
A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszekundumos eltérések akár katasztrofális következményekkel járhatnak. Éppen ezért sokáig a robotok közvetlen vezérlésének kiszervezése a felhőbe nem volt megoldható. A peremhálózati rendszerekkel viszont ez megváltozhat.
|
A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszekundumos eltérések akár katasztrofális következményekkel járhatnak. Éppen ezért sokáig a robotok közvetlen vezérlésének kiszervezése a felhőbe nem volt megoldható. A peremhálózati rendszerekkel viszont ez megváltozhat.
|
||||||
|
|
||||||
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.
|
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ó demonstráció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
|
\section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése
|
||||||
|
|
||||||
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.
|
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ába 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}}
|
\subsection{\textit{Universal Robots}}
|
||||||
|
|
||||||
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
|
A demonstráció során használt robotkarokat a \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 a dolgozatí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 \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, amely 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 demonstráció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}.
|
||||||
|
|
||||||
@ -28,7 +28,7 @@ A demonstrációhoz használt két robotkar típusa \textit{UR3} és \textit{UR3
|
|||||||
|
|
||||||
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.
|
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}.
|
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$-ban 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}.
|
||||||
|
|
||||||
A két robotkar végére két különböző gripper van telepítve, mindkettő \textit{OnRobot} gyártmány, viszont az egyik egy \textit{rg2} a másik pedig \textit{rg2-ft}. Fizikai jellemzőit tekintve a két gripper hasonló: mindkettő képes legalább 100mm-re kinyílni és 2 kilogramm erővel vízszintesen tömeget megemelni. A szorításra maximum 40 Newton erőt képesek kifejteni \cite{rg2datasheet,rg2tftdatasheet}. A fő különbséget a gripperek kommunikációs interfésze nyújtja.
|
A két robotkar végére két különböző gripper van telepítve, mindkettő \textit{OnRobot} gyártmány, viszont az egyik egy \textit{rg2} a másik pedig \textit{rg2-ft}. Fizikai jellemzőit tekintve a két gripper hasonló: mindkettő képes legalább 100mm-re kinyílni és 2 kilogramm erővel vízszintesen tömeget megemelni. A szorításra maximum 40 Newton erőt képesek kifejteni \cite{rg2datasheet,rg2tftdatasheet}. A fő különbséget a gripperek kommunikációs interfésze nyújtja.
|
||||||
|
|
||||||
@ -38,15 +38,15 @@ A két robotkar végére két különböző gripper van telepítve, mindkettő \
|
|||||||
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}:
|
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}
|
\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{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. Ez az interfész elsősorban 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 é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{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{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{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{\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 a robotok egyes funkcióit 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).
|
\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).
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
@ -55,11 +55,11 @@ Emellett a hozzákapcsolt grippereknek is lehet önálló kommunikációs interf
|
|||||||
|
|
||||||
\subsubsection{\textit{URScript}}
|
\subsubsection{\textit{URScript}}
|
||||||
|
|
||||||
Az \textit{URScript} imperatív, interpretált szkriptnyelv, amelyet elsősorban robotikai alkalmazásokra fejlesztettek ki \cite{urscriptreference}. A nyelv szintaktikája sokban hasonlít a \gls{python} programozási nyelvre.
|
A \textit{URScript} imperatív, interpretált szkriptnyelv, amelyet elsősorban robotikai alkalmazásokra fejlesztettek ki \cite{urscriptreference}. A nyelv szintaktikája sokban hasonlít a \gls{python} programozási nyelvre.
|
||||||
|
|
||||||
A fő eltérés a \gls{python} programozási nyelvhez képest, hogy explicit jelezni kell, ha egy blokk véget ér (\texttt{end} kulcsszó). URScript snippeteket gyakran \textit{on-the-fly} tudunk küldeni valamilyen \acrshort{tcp} kapcsolaton keresztül. Feltételezhetően ez miatt kell jelölni a blokkok végét, hiszen másként nem lenne lehetősége a vezérlő szoftvernek eldönteni, hogy egy blokk véget ért-e.
|
A fő eltérés a \gls{python} programozási nyelvhez képest, hogy explicit jelezni kell, ha egy blokk véget ér (\texttt{end} kulcsszó). URScript snippeteket gyakran \textit{on-the-fly} tudunk küldeni \acrshort{tcp} kapcsolaton keresztül. Feltételezhetően ez miatt kell jelölni a blokkok végét, hiszen másként nem lenne lehetősége a vezérlő szoftvernek eldönteni, hogy egy blokk véget ért-e.
|
||||||
|
|
||||||
Az \textit{URScript} programokban lehetőség van többszálúsítást alkalmazni. Az egyes szálakat hagyományos módon függvény szerűen tudjuk definiálni. Mivel az \textit{URScript} elsődleges felhasználása, hogy robotokat vezéreljen valós időben, ezért a szálak ütemezése is erre alapozott.
|
Az \textit{URScript} programokban lehetőség van többszálúsítást alkalmazni. Az egyes szálakat hagyományos módon függvény szerűen tudjuk definiálni. Mivel a \textit{URScript} elsődleges felhasználása, hogy robotokat vezéreljen valós időben, ezért a szálak ütemezése is erre alapozott.
|
||||||
|
|
||||||
A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást adni nekik). Hogy ezt megvalósíthassa, a végrehajtó környezet minden szálnak pontosan 8ms időt allokál, hogy fusson. A futásra készen álló szálakból \textit{round-robin} ütemezés szerint választ az ütemező. % TODO itt kibogarászni hogy a physical idő meg a timeframe-ek hogy vannak
|
A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást adni nekik). Hogy ezt megvalósíthassa, a végrehajtó környezet minden szálnak pontosan 8ms időt allokál, hogy fusson. A futásra készen álló szálakból \textit{round-robin} ütemezés szerint választ az ütemező. % TODO itt kibogarászni hogy a physical idő meg a timeframe-ek hogy vannak
|
||||||
|
|
||||||
@ -76,7 +76,7 @@ Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy iz
|
|||||||
|
|
||||||
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.
|
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.
|
Bár egyszerűnek tűnik, ebben a szcenárióban nagy hangsúly helyeződik a hálózat pontos időzítésérére, hiszen a kritikus ponton, amikor a két robotkar összeilleszti 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 ennek a szoftvernek a 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.
|
||||||
|
|
||||||
@ -96,20 +96,20 @@ Az asztalon a két munkadarabnak kijelölt helye van, ahonnan a robotkarok felem
|
|||||||
\subsubsection{Vezérlés}
|
\subsubsection{Vezérlés}
|
||||||
\label{sec:ursim_demo_control}
|
\label{sec:ursim_demo_control}
|
||||||
|
|
||||||
A demo vezérlésére a munkám elején egy \gls{python} nyelven megírt monolit program állt rendelkezésemre. A program úgy lett tervezve, hogy elindításával csatlakozik mindkettő robotkar \acrshort{rtde} interfészére. Majd sorban elküldi a robotkaroknak a demo végrehajtásához szükséges utasításokat. A % TODO
|
A demo vezérlésére a munkám elején egy \gls{python} nyelven megírt monolit program állt rendelkezésemre. A program úgy lett tervezve, hogy elindításával csatlakozik mindkettő robotkar \acrshort{rtde} interfészére, majd sorban elküldi a robotkaroknak a demo végrehajtásához szükséges utasításokat. A % TODO
|
||||||
gripper vezérlését \acrshort{rest} \acrshort{api}-n keresztül végzi.
|
gripper vezérlését \acrshort{rest} \acrshort{api}-n keresztül végzi.
|
||||||
|
|
||||||
A két robotkar vezérlése két külön szálon van megvalósítva. Mindkettő szálon egymás után következnek az utasítások, a kritikus szinkronizációs részek egyszerű szál-szinkronizációs primitívekkel vannak megoldva.
|
A két robotkar vezérlése két külön szálon van megvalósítva. Mindkettő szálon egymás után következnek az utasítások, a kritikus szinkronizációs részek egyszerű szál-szinkronizációs primitívekkel vannak megoldva.
|
||||||
|
|
||||||
A programban több futtatási mód is implementálva van. Egyrészt gyors és lassú végrehajtás sebesség között lehet választani. Ez a robotkarok mozgási sebességét befolyásolja. Emellett úgynevezett \enquote{Jogging} módban is lehet az alkalmazást futtatni. Ebben a módban a program minden mozdulat végrehajtása előtt várakozik egy gomb lenyomására a további parancsok kiadása előtt. Így lehetőség adódik az esetleges hibás mozgások hibakeresésére, illetve a program teljesen automatikus lefuttatása előtt manuális tesztelésre.
|
A programban több futtatási mód is implementálva van. Egyrészt gyors és lassú végrehajtási sebesség között lehet választani. Ez a robotkarok mozgási sebességét befolyásolja. Emellett úgynevezett \enquote{Jogging} módban is lehet az alkalmazást futtatni. Ebben a módban a program minden mozdulat végrehajtása előtt várakozik egy gomb lenyomására a további parancsok kiadása előtt. Így lehetőség adódik az esetleges hibás mozgások hibakeresésére, illetve a program teljesen automatikus lefuttatása előtt manuális tesztelésre.
|
||||||
|
|
||||||
A program a konfigurációs beállításait egy \gls{ini} fájlban tárolja. Ezek a konfigurációs beállítások elsősorban a robotkarok és a hozzá tartozó gripperek hálózati címeit adja meg, illetve a konkrét sebesség módokhoz tartozó konfigurációs értékeket.
|
A program a konfigurációs beállításait egy \gls{ini} fájlban tárolja. Ezek a konfigurációs beállítások elsősorban a robotkarok és a hozzá tartozó gripperek hálózati címeit adja meg, illetve a konkrét sebesség módokhoz tartozó konfigurációs értékeket.
|
||||||
|
|
||||||
Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinátákat egy \textit{Microsoft Excel} \gls{xlsx} fájlból olvassa ki. Ebben a fájlban mindkét robotkarhoz tartozóan fel vannak sorolva az egyes pózok leírásai sorrendben. % koordináták mind tool- és joint térben. %TODO verify naming
|
Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinátákat egy \textit{Microsoft Excel} \gls{xlsx} fájlból olvassa ki. Ebben a fájlban mindkét robotkarhoz tartozóan fel vannak sorolva az egyes pózok leírásai sorrendben. % koordináták mind tool- és joint térben. %TODO verify naming
|
||||||
|
|
||||||
\section{Felkészítés a peremhálózati alkalmazásra} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
|
\section{Felkészítés a peremhálózati alkalmazásra} % Itt foglalom össze, hogy hogy terveztem meg
|
||||||
|
|
||||||
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.
|
A fenti monolit demó átültetése alapos tervezést igényelt egy felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
|
||||||
|
|
||||||
\subsection{Architektúra}
|
\subsection{Architektúra}
|
||||||
|
|
||||||
@ -117,7 +117,7 @@ Mivel a \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatás
|
|||||||
|
|
||||||
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.
|
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.
|
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úra 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!]
|
\begin{figure}[h!]
|
||||||
\centering
|
\centering
|
||||||
@ -128,16 +128,16 @@ A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_servi
|
|||||||
|
|
||||||
\subsubsection{\textit{On-site} réteg}
|
\subsubsection{\textit{On-site} réteg}
|
||||||
|
|
||||||
Mivel azt szeretnénk, hogy a telephelyen belüli (On-site) rendszer a lehető legminimálisabb legyen, így oda csak maga a robotkar -- és a hozzá tartozó \textit{Control Box} amely az alacsony szintű vezérlését megvalósítja -- kerül. Természetesen ebből több is kerülhet egy telephelyre, vagy akár több telephelyre kihelyezett rendszert is irányíthatunk egyszerre.
|
Mivel azt szeretnénk, hogy a telephelyen belüli (On-site) rendszer a lehető legminimálisabb legyen, így oda csak maga a robotkar -- és a hozzá tartozó \textit{Control Box}, amely az alacsony szintű vezérlését megvalósítja -- kerül. Természetesen ebből több is kerülhet egy telephelyre, vagy akár több telephelyre kihelyezett rendszert is irányíthatunk egyszerre.
|
||||||
|
|
||||||
\subsubsection{Peremhálózati réteg}
|
\subsubsection{Peremhálózati réteg}
|
||||||
\label{sec:edge_layer_plans}
|
\label{sec:edge_layer_plans}
|
||||||
|
|
||||||
A középső rétegben alacsony késleltetésünk van a robotkar felé, viszont csak limitált erőforrásaink vannak. Ennek érdekében csak azokat a komponenseket lenne érdemes ide tenni, amelynél ezek a szempontok fontosak és azt is minimálisan tartani. Ezen a szinten ezért egy \enquote{középszintű} vezérlő komponenst terveztem. Ez már az általam írt kód szerint dolgozik, így tetszőleges logikát tudok bele implementálni. Az alacsony késleltetés miatt innen megbízhatóan és közvetlenül lehet a robotkarnak mozgató utasításokat kiadni illetve az állapotát beolvasni.
|
A középső rétegben alacsony késleltetésünk van a robotkar felé, viszont csak limitált erőforrásaink vannak. Ennek érdekében csak azokat a komponenseket lenne érdemes ide tenni, amelyeknél ezek a szempontok fontosak és azt is minimálisan tartani. Ezen a szinten ezért egy \enquote{középszintű} vezérlő komponenst terveztem. Ez már az általam írt kód szerint dolgozik, így tetszőleges logikát tudok bele implementálni. Az alacsony késleltetés miatt innen megbízhatóan és közvetlenül lehet a robotkarnak mozgató utasításokat kiadni illetve az állapotát beolvasni.
|
||||||
|
|
||||||
A \enquote{középszintű} vezérlés feladata egy olyan absztrakciót adni az egyel magasabb réteg felé, hogy ott már olyan módon lehessen irányítani a robotok működését, hogy azt ne zavarja a késleltetés. Ezt az absztrakciót úgy terveztem meg, hogy nagyobb, összefüggő lépés sorozatok végrehajtását tegye lehetővé a magasabb réteg felé.
|
A \enquote{középszintű} vezérlés feladata egy olyan absztrakciót adni az egyel magasabb réteg felé, hogy ott már olyan módon lehessen irányítani a robotok működését, hogy azt ne zavarja a késleltetés. Ezt az absztrakciót úgy terveztem meg, hogy nagyobb, összefüggő lépés sorozatok végrehajtását tegye lehetővé a magasabb réteg felé.
|
||||||
|
|
||||||
A lépés sorozatoknál elvárás, hogy biztonságos állapotból indulnak és biztonságos állapotba érkeznek. Így a kettő lépés sorozat végrehajtása között eltelt idő nem befolyásolja károsan a rendszert. A lépés sorozatok engednek egy bizonyos fokú külső befolyást is, viszont ezeket szigorúan úgy kell implementálni, hogy itt se számítson a késleltetése a beavatkozásoknak.
|
A lépés sorozatoknál elvárás, hogy biztonságos állapotból indulnak és biztonságos állapotba érkeznek. Így a kettő lépés sorozat végrehajtása között eltelt idő nem befolyásolja károsan a rendszert. A lépés sorozatok engednek bizonyos fokú külső befolyást is, viszont ezeket szigorúan úgy kell implementálni, hogy itt se számítson a késleltetése a beavatkozásoknak.
|
||||||
|
|
||||||
A lépés sorozatokat \textit{Program}nak neveztem el. Egy ilyen \textit{program} lépéseinek végrehajtása a futtatás. A magasabb rétegek ilyen előre összeállított programokat képesek a peremhálózati rendszer felé küldeni, illetve annak futási állapotáról információkat kapni.
|
A lépés sorozatokat \textit{Program}nak neveztem el. Egy ilyen \textit{program} lépéseinek végrehajtása a futtatás. A magasabb rétegek ilyen előre összeállított programokat képesek a peremhálózati rendszer felé küldeni, illetve annak futási állapotáról információkat kapni.
|
||||||
|
|
||||||
@ -149,12 +149,12 @@ Mivel a peremhálózati rétegben már kialakítottunk egy absztrakciót, amely
|
|||||||
|
|
||||||
Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data}, azaz a nagy mennyiségű adat gyűjtése és feldolgozása és ennek felhasználása.
|
Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data}, azaz a nagy mennyiségű adat gyűjtése és feldolgozása és ennek felhasználása.
|
||||||
|
|
||||||
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.
|
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 elkészített rendszerben a mérési adatok gyűjtése és feldolgozása kimerül annak magas szintű tervezésében.
|
||||||
|
|
||||||
\subsection{Peremhálózati szolgáltatások} % Peremhálózati rendszer basically
|
\subsection{Peremhálózati szolgáltatások} % Peremhálózati rendszer basically
|
||||||
\label{sec:single_robot_contoller_plans}
|
\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.
|
\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 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 demonstráció 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.
|
||||||
|
|
||||||
@ -165,20 +165,20 @@ Emellett meg kell oldania olyan problémákat is, amelyek \aref{sec:ursim_demo_c
|
|||||||
|
|
||||||
Annak érdekében, hogy a komponens absztrakt módon megoldást adjon a késleltetések áthidalására a felhő és a peremhálózati rendszerek között a robot mozgatásához szükséges lépéseket egy \textit{program}ba szedve kapja meg. Egy ilyen \textit{program} utasításokból épül fel, amelyet interpretáltan, imperatív módon hajt végre a komponens.
|
Annak érdekében, hogy a komponens absztrakt módon megoldást adjon a késleltetések áthidalására a felhő és a peremhálózati rendszerek között a robot mozgatásához szükséges lépéseket egy \textit{program}ba szedve kapja meg. Egy ilyen \textit{program} utasításokból épül fel, amelyet interpretáltan, imperatív módon hajt végre a komponens.
|
||||||
|
|
||||||
Szerettem volna egy olyan végrehajtási környezetet megalkotni, ahol könnyen lehet az egyes utasítások mögött cserélni a funkcionalitást. Ezzel egyrészt lehetőség nyílik arra, hogy a programokat szinte módosítás nélkül újrahasznosítsuk.
|
Szerettem volna egy olyan végrehajtási környezetet megalkotni, ahol könnyen lehet az egyes utasítások mögött cserélni a funkcionalitást. Ezzel lehetőség nyílik arra, hogy a programokat szinte módosítás nélkül újrahasznosítsuk.
|
||||||
|
|
||||||
Munkám során mások is dolgoztak a robotkarok alacsony szintű vezérlésén. Terveink szerint ezeket a törekvéseket egy projektben fogjuk majd egyesíteni. Ez is alátámasztotta a dinamikusan cserélhető funkcionalitás szükségességét.
|
Munkám során mások is dolgoztak a robotkarok alacsony szintű vezérlésén. Terveink szerint ezeket a törekvéseket egy projektben fogjuk majd egyesíteni. Ez is alátámasztotta a dinamikusan cserélhető funkcionalitás szükségességét.
|
||||||
|
|
||||||
Ezek motiválták, hogy az egyes utasításokat önálló komponensbe szervezzem. Ezeket a komponenseket \textit{plugin}-nak neveztem el. A \textit{program} által végrehajtható utasításokat az egyes \textit{plugin}-ok implementálják. Egy \textit{plugin} többet is akár, illetve egy utasítást több \textit{plugin} is implementálhat\footnote{Ilyen esetben csak egy \textit{plugin}-t használhatunk egyszerre}. Ennek köszönhetően egy utasítás mögött egy másik \textit{plugin} használatával könnyen lecserélhetjük a funkcionalitást. A program futtatása előtt definiálni kell, hogy konkrétan melyik \textit{plugin}-okat szeretnénk használni a futtatás során.
|
Ezek motiválták, hogy az egyes utasításokat önálló komponensbe szervezzem. Ezeket a komponenseket \textit{plugin}-nak neveztem el. A \textit{program} által végrehajtható utasításokat az egyes \textit{plugin}-ok implementálják. Egy \textit{plugin} többet is akár, illetve egy utasítást több \textit{plugin} is implementálhat\footnote{Ilyen esetben csak egy \textit{plugin}-t használhatunk egyszerre}. Ennek köszönhetően egy utasítás mögött egy másik \textit{plugin} használatával könnyen lecserélhetjük a funkcionalitást. A program futtatása előtt definiálni kell, hogy konkrétan melyik \textit{plugin}-okat szeretnénk használni a futtatás során.
|
||||||
|
|
||||||
Egy \textit{plugin} által definiált utasítás a funkcionalitás mellett annak végrehajtásának vége előtti megszakítását is implementálnia kell, hiszen bármikor előfordulhat olyan helyzet, hogy le kell állítani a futtatást. Emellett a végrehajtás állapotának megfigyelhetőségéhez szükséges funkciókat is meg kell valósítania.
|
Egy \textit{plugin} által definiált utasításnak, a funkcionalitás mellett, végrehajtásának vége előtti megszakítását is implementálnia kell, hiszen bármikor előfordulhat olyan helyzet, hogy le kell állítani a futtatást. Emellett a végrehajtás állapotának megfigyelhetőségéhez szükséges funkciókat is meg kell valósítania.
|
||||||
|
|
||||||
\subsubsection{Szinkronizáció}
|
\subsubsection{Szinkronizáció}
|
||||||
\label{sec:ursim_snyc_proto}
|
\label{sec:ursim_snyc_proto}
|
||||||
|
|
||||||
A demonstráció 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.
|
Mivel itt már nem két szál összehangolásáról van szó, hanem két egymástól független alkalmazásról, 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 teljesen más megoldást kívánt.
|
||||||
|
|
||||||
Alapos kutatás után sajnos nem találtam erre a problémára teljes, kész megoldást, ezért kidolgoztam egy saját megoldást.
|
Alapos kutatás után sajnos nem találtam erre a problémára teljes, kész megoldást, ezért kidolgoztam egy saját megoldást.
|
||||||
|
|
||||||
@ -204,17 +204,17 @@ A szinkronizációs folyamat időbeni lefutása \aref{fig:pyprocsync_flow} ábr
|
|||||||
A protokoll arra hagyatkozik, hogy ismerjük, hogy hány komponenst kell szinkronizálni. Mindig, amikor egy program a szinkronizációs ponthoz érkezik, akkor atomikus módon megnövel egy számlálót, ha a számláló értéke egyezik, a várakozó komponensek számával, akkor az utolsó komponens a pillanatnyi rendszeridőhöz hozzáad egy fix értéket, és ezt kihirdeti a többi komponens felé\footnote{Ha feltételezzük, hogy a rendszeridők szinkronban vannak, akkor lényegében mindegy, hogy melyik komponens hirdeti ki.}. Erre a hozzáadásra azért van szükség, hogy ellensúlyozza azt az időt (ami a hálózati késleltetésből adódóan változó lehet), amíg az üzenet eljut minden komponenshez. Ezek után a komponensek a kihirdetett időben folytatják a végrehajtást.
|
A protokoll arra hagyatkozik, hogy ismerjük, hogy hány komponenst kell szinkronizálni. Mindig, amikor egy program a szinkronizációs ponthoz érkezik, akkor atomikus módon megnövel egy számlálót, ha a számláló értéke egyezik, a várakozó komponensek számával, akkor az utolsó komponens a pillanatnyi rendszeridőhöz hozzáad egy fix értéket, és ezt kihirdeti a többi komponens felé\footnote{Ha feltételezzük, hogy a rendszeridők szinkronban vannak, akkor lényegében mindegy, hogy melyik komponens hirdeti ki.}. Erre a hozzáadásra azért van szükség, hogy ellensúlyozza azt az időt (ami a hálózati késleltetésből adódóan változó lehet), amíg az üzenet eljut minden komponenshez. Ezek után a komponensek a kihirdetett időben folytatják a végrehajtást.
|
||||||
|
|
||||||
|
|
||||||
A szinkronizációs megoldást önállóan elérhető \gls{python} csomagként is publikáltam, így más projektekben is felhasználható\footnote{\url{https://github.com/marcsello/pyprocsync}}. Sajnos az implementáció csak \textit{Redis}-el működik.
|
A szinkronizációs megoldást önállóan elérhető \gls{python} csomagként is publikáltam, így más projektekben is felhasználható\footnote{\url{https://github.com/marcsello/pyprocsync}}. Sajnos az implementáció csak \textit{Redis}-szel működik.
|
||||||
|
|
||||||
\subsubsection{Megfigyelés és vezérlés}
|
\subsubsection{Megfigyelés és vezérlés}
|
||||||
|
|
||||||
A szolgáltatásnak lehetőséget kell adni arra, hogy működése megfigyelhető és beavatkozható legyen. Erre a célra egy \acrshort{http} \acrshort{api}-t terveztem.
|
A szolgáltatásnak lehetőséget kell adni arra, hogy működése megfigyelhető legyen és be lehessen abba avatkozni. Erre a célra egy \acrshort{http} \acrshort{api}-t terveztem.
|
||||||
|
|
||||||
Azért ezt a megoldást választottam, mert a \acrshort{http} protokoll kellően elterjedt, ezért széleskörűen támogatott. Mivel a futtatókörnyezet \textit{Kubernetes} alapú, ezért ez a legkönnyebben kezelhető hálózati erőforrás. %TODO: alátámasztani/megindokolni
|
Azért ezt a megoldást választottam, mert a \acrshort{http} protokoll kellően elterjedt, ezért széleskörűen támogatott. Mivel a futtatókörnyezet \textit{Kubernetes} alapú, ezért ez a legkönnyebben kezelhető hálózati erőforrás. %TODO: alátámasztani/megindokolni
|
||||||
|
|
||||||
Az \acrshort{api} két fontos és fix funkciót kell kiszolgáljon. Szükség esetén a program futását meg kell tudni szakítani (akár egy lépés végrehajtása közben is), emellett a program futásának állapotát is lekérhetővé teszi.
|
Az \acrshort{api} két fontos és fix funkciót kell kiszolgáljon. Szükség esetén a program futását meg kell tudni szakítani (akár egy lépés végrehajtása közben is), emellett a program futásának állapotát is lekérhetővé teszi.
|
||||||
|
|
||||||
A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrshort{api} használatával lehet elérni. Ennek segítségével meg lehet valósítani a \enquote{jogging} futtatást egy olyan \textit{plugin}nel ami minden fő lépés után meghívásra kerül és várakozik az endpoint meghívására.
|
A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrshort{api} használatával lehet elérni. Ennek segítségével meg lehet valósítani a \enquote{jogging} futtatást egy olyan \textit{plugin}nel, ami minden fő lépés után meghívásra kerül és várakozik az endpoint meghívására.
|
||||||
|
|
||||||
\subsection{Felhő szolgáltatások}
|
\subsection{Felhő szolgáltatások}
|
||||||
\label{sec:cloud_layer_plans}
|
\label{sec:cloud_layer_plans}
|
||||||
@ -248,7 +248,7 @@ Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől é
|
|||||||
|
|
||||||
\section{Implementáció}
|
\section{Implementáció}
|
||||||
|
|
||||||
Az összes általam választott szolgáltatást \gls{python} nyelven implementáltam le. Mivel népszerű programnyelv ezért mind a robotkarok vezérlésére, mind pedig a többi felhasználásra kész programozói könyvtárakkal rendelkezik, így ez egy kézenfekvő választás volt.
|
Az összes általam választott szolgáltatást \gls{python} nyelven implementáltam le. Mivel népszerű programnyelv ezért mind a robotkarok vezérlésére, mind pedig a többi felhasználásra kész programozói könyvtárakkal rendelkezik, így ez kézenfekvő választás volt.
|
||||||
|
|
||||||
% ha nagyon kevés oldal van, akkor itt tudok írni a fejlesztői környezetről is illetve a tesztelésről
|
% ha nagyon kevés oldal van, akkor itt tudok írni a fejlesztői környezetről is illetve a tesztelésről
|
||||||
|
|
||||||
@ -316,9 +316,9 @@ Amikor a program futása erre a pontra érkezik, akkor az várakozni fog egésze
|
|||||||
|
|
||||||
Ez a \textit{plugin} jelenleg az egyetlen, amely a robotkar irányítását megvalósítja.
|
Ez a \textit{plugin} jelenleg az egyetlen, amely a robotkar irányítását megvalósítja.
|
||||||
|
|
||||||
Inicializációkor csatlakozik a robotkar \acrshort{rtde} interfészére, amelyre blokkoló módon küldi a mozgási utasításokat. Ennek értelmében a cím amelyre csatlakoznia kell már itt rendelkezésre kell állnia, így azt a program konfigurációjaként adhatjuk meg.
|
Inicializációkor csatlakozik a robotkar \acrshort{rtde} interfészére, amelyre blokkoló módon küldi a mozgási utasításokat. Ennek értelmében a cím, amelyre csatlakoznia kell, már itt rendelkezésre kell állnia, így azt a program konfigurációjaként adhatjuk meg.
|
||||||
|
|
||||||
Minden egyes utasítás akkor ér véget, ha a mozgás befejeződött, így tud a következő utasításra lépni. Hiba esetén az \acrshort{rtde} interfész lehetőséget ad arra, hogy közölje azzal aki az utasítást adta. Így egy utasítás hibájával (például érvénytelen mozgás, váratlan akadály vagy kézi megszakítás) a teljes \textit{program} végrehajtása megáll.
|
Minden egyes utasítás akkor ér véget, ha a mozgás befejeződött, így tud a következő utasításra lépni. Hiba esetén az \acrshort{rtde} interfész lehetőséget ad arra, hogy ezt közölje azzal, aki az utasítást adta. Így egy utasítás hibájával (például érvénytelen mozgás, váratlan akadály vagy kézi megszakítás) a teljes \textit{program} végrehajtása megáll.
|
||||||
|
|
||||||
\subsubsection{\textit{Wait Plugin}}
|
\subsubsection{\textit{Wait Plugin}}
|
||||||
|
|
||||||
@ -342,9 +342,9 @@ A fent vázolt \textit{plugin}ek mellett készítettem néhány egyszerűbbet 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 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.
|
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.
|
||||||
|
|
||||||
A verzió mellett a leírás tartalmazza a program nevét, ennek nem kell egyedinek lennie csak diagnosztikai céllal létezik. Emellett a program létrehozásának időpontját és a betöltendő \textit{plugin}ek listáját.
|
A verzió mellett a leírás tartalmazza a program nevét, ennek nem kell egyedinek lennie, csak diagnosztikai céllal létezik, emellett a program létrehozásának időpontját és a betöltendő \textit{plugin}ek listáját is.
|
||||||
|
|
||||||
A \textit{program} leírása opcionálisan tartalmazhat egy \texttt{id} vagy \texttt{\_id} mezőt, ezzel megkönnyítve a program kezelését. A beolvasásnál ennek a mezőnek a jelenléte nem okoz hibát.
|
A \textit{program} leírása opcionálisan tartalmazhat egy \texttt{id} vagy \texttt{\_id} mezőt, ezzel megkönnyítve a program kezelését. A beolvasásnál ennek a mezőnek a jelenléte nem okoz hibát.
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user