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

small fixes

This commit is contained in:
Pünkösd Marcell 2021-05-23 17:22:07 +02:00
parent 93f5317427
commit 335abf4c78
4 changed files with 70 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/content/birbnetes_impl.tex
View File

@ -4,7 +4,7 @@
\label{chapter:birbnetes}
%----------------------------------------------------------------------------
Éves szinten komoly károkat tudnak okozni a szőlőtermő vidékeken a termést előszeretettel fogyasztó seregély madarak\cite{seregelykar}. Jelenleg kevés hatékony megoldás van arra, hogy a szőlősgazdák meg tudják védeni a termést a kártékony madaraktó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 a kártékony madaraktó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.
@ -30,9 +30,9 @@ Az algoritmusok elméleti működéséről a következő fejezetek adnak átteki
\subsubsection{\acrlong{svm}}
A gépi tanulás kontextusában az \acrshort{svm} egy felügyelt tanulási módszer, amelyet többek között a klasszifikációs feladatok megoldására tudnak eredményesen használni\cite{scikit_svm}. Fontos előnye, hogy nagyon hatékonynak tekinthető az erőforrás használat szempontjából.
A gépi tanulás kontextusában az \acrshort{svm} egy felügyelt tanulási módszer, amelyet többek között a klasszifikációs feladatok megoldására tudnak eredményesen használni \cite{scikit_svm}. Fontos előnye, hogy nagyon hatékonynak tekinthető az erőforrás használat szempontjából.
Működésének alapját az adja, hogy úgy próbálja az adathalmazt felosztani osztályokra, hogy megkeresi egy vélt választó vonalhoz legközelebb eső pontokat (support vectorokat), majd azon dolgozik hogy a választó vonal és ezen pontok távolsága a legnagyobb legyen. Az algoritmus egyszerű dimenzióváltásoknak köszönhetően nagyon hatékonyan tud magasabb dimenziókban is problémát megoldani\cite{medium_svm}.
Működésének alapját az adja, hogy úgy próbálja az adathalmazt felosztani osztályokra, hogy megkeresi egy vélt választó vonalhoz legközelebb eső pontokat (support vectorokat), majd azon dolgozik hogy a választó vonal és ezen pontok távolsága a legnagyobb legyen. Az algoritmus egyszerű dimenzióváltásoknak köszönhetően nagyon hatékonyan tud magasabb dimenziókban is problémát megoldani \cite{medium_svm}.
% TODO Ide szülni még egy bekezdést, hogy az itt hogy jó nekünk
@ -40,9 +40,9 @@ 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}
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. Mint azt a neve is mutatja, neuronokból áll. Minden egyes neuronnak van egy bemenete és egy kimenete. A neuronok belsejében pedig egy aktivációs függvény van, amely alapján a kimenetet számolja. Ezeket a neuronokat rétegekbe szervezik, és oly módon kötik össze őket, hogy az egyes rétegekben lévő neuronok, az előttük lévő réteg kimenetét kapják meg bemenet gyanánt. Egy ilyen konstrukciót nevezünk neurális hálónak \cite{medium_nn}. A háló minden éle rendelkezik úgynevezett súlyozással, itt mi ezeknek a súlyozásoknak az összességét és magának a hálónak a felépítését egy csomagban modellnek nevezzük.
A konvolúciós neurális hálóknak (\acrlong{cnn}; \acrshort{cnn}) nagyon széles felhasználási köre van, a mozgókép felismeréstől az ajánló rendszereken át a természetes nyelvfeldolgozásig. A konvolúciós neurális hálók a neurális hálók egy speciális fajtája, ahol az egyes rétegek konvolúciót valósítanak meg\cite{medium_cnn}.
A konvolúciós neurális hálóknak (\acrlong{cnn}; \acrshort{cnn}) nagyon széles felhasználási köre van, a mozgókép felismeréstől az ajánló rendszereken át a természetes nyelvfeldolgozásig. A konvolúciós neurális hálók a neurális hálók egy speciális fajtája, ahol az egyes rétegek konvolúciót valósítanak meg \cite{medium_cnn}.
Az alkalmazott megoldás a beérkező hangokból spektrogramot generál, majd ezeket képként értelmezve végez rajtuk felismerést. Mivel a konvolúciós neurális hálókat eredményesen használják képfelismerésre, ezért ez egy kézenfekvő megoldás itt is.
@ -137,14 +137,14 @@ A rendszerhez készült egy webes kezelőfelület is, amelyet hallgatótársunk
Az általunk tervezett és implementált mikroszolgáltatások működéséről és felelősségeiről egy rövid leírás olvasható az alábbiakban.
\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.
\item \textbf{Storage Service} Ez a szolgáltatás valósítja meg a hangfájlok hosszútávú tárolását egy objektum tárolóban. Képes kérésre visszaadni a hangfájlokat, illetve törölni is a mintákat.
\item \textbf{\acrshort{ai} Service} Ez a szolgáltatás valósítja meg a beérkezett hangmintán hallható madár hang konkrét azonosítását. Ehhez \acrshort{cnn} algoritmust használ. Mind a folyamat elkezdéséhez szükséges üzenet fogadását, mind az eredmény publikálását üzenet sorokra kapcsolódva valósítja meg. A működéséhez szükséges modellt a \textit{Model Service} komponensből tölti le, amellyel \acrshort{rest} interfészen kommunikál. A hangmintát tag alapján a \textit{Storage Service}-ből tölti le címke alapján. Az adott eredmény egy hangminta címkéje és a felismert osztály (amely modelltől függően egy madár faj lehet).
\item \textbf{\acrshort{ai} Service} Ez a szolgáltatás valósítja meg a beérkezett hangmintán hallható madár hang konkrét azonosítását. Ehhez \acrshort{cnn} algoritmust használ. Mind a folyamat elkezdéséhez szükséges üzenet fogadását, mind az eredmény publikálását üzenet sorokra kapcsolódva valósítja meg. A működéséhez szükséges modellt a \textit{Model Service} komponensből tölti le, amellyel \acrshort{rest} interfészen kommunikál. A hangmintát a \textit{Storage Service}-ből tölti le címke alapján. Az adott eredmény egy hangminta címkéje és a felismert osztály (amely modelltől függően egy madár faj lehet).
\item \textbf{Model Service} Ez egyfajta okos tároló a rendszerben használt különböző \acrshort{mi} algoritmusok által használt modellek tárolására és kezelésére. Nem csak magát a modellt de arról különböző metaadatokat is képes eltárolni, amelyeket automatikusan olvas be a modellből. Ilyen például, hogy milyen modelleket képes azonosítani, ezekből melyik jelent veszélyt vagy, hogy az előfeldolgozásánál a hangnak milyen paramétereket kell használni.
\item \textbf{Model Service} Ez egyfajta okos tároló a rendszerben használt különböző \acrshort{mi} algoritmusok által használt modellek tárolására és kezelésére. Nem csak magát a modellt, de arról különböző metaadatokat is képes eltárolni, amelyeket automatikusan olvas be a modellből. Ilyen például, hogy milyen osztályokat (esetünkben madarakat) képes azonosítani, ezekből melyik jelent veszélyt vagy, hogy az előfeldolgozásánál a hangnak milyen paramétereket kell használni.
\item \textbf{Results Service} Ez a szolgáltatás az egyes mintákra való kiértékelések eredményét tárolja le. Minden mintára az eredmények egyértelműen visszakereshetőek és lekérdezhetőek. Ennek a megoldására relációs adatbázist használ.

2
src/content/introduction.tex
View File

@ -3,7 +3,7 @@
\chapter{\bevezetes}
%----------------------------------------------------------------------------
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}.
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}.
% itt csak megemlítem a problémákat

44
src/content/overview.tex
View File

@ -11,21 +11,21 @@
\subsection{Általánosságban a felhőről}
Általánosságban véve az informatikában akkor beszélhetünk felhőről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. Ebben a megközelítésben a környezet üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által fenntartott -- \gls{adatkozpont}ban foglal helyet.
Általánosságban véve az informatikában akkor beszélhetünk felhőről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk \cite{what_is_cloud}. Ebben a megközelítésben a környezet üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által fenntartott -- \gls{adatkozpont}ban foglal helyet.
A felhőszolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
általános hardverelemek használatára visszavezethető alacsonyabb beruházási költség és az automatizált
folyamatok biztosította alacsonyabb üzemeltetési költség\cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.
folyamatok biztosította alacsonyabb üzemeltetési költség \cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.
Gyakran a felhőszolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.
Gyakran a felhőszolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést \cite{geodist}.
A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgynevezett \acrfull{saas} (Szoftver mint szolgáltatás), amely egy előre telepített szoftver eszközt biztosít a szolgáltató felhő környezetében, amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.
Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak\cite{cloudadpotation}.
Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak \cite{cloudadpotation}.
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é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}.
\subsection{Felhős alkalmazásüzemeltetési eszközök}
@ -40,9 +40,9 @@ Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image)
\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ő 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.
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.
@ -54,7 +54,7 @@ Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Depl
\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 Alkalmazás programozói interfész (\acrlong{api}; \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 Alkalmazás programozói interfész (\acrlong{api}; \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.
@ -81,9 +81,9 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
\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 értelmezik \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:
\begin{itemize}
@ -114,9 +114,9 @@ Ezt a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amely
\label{fig:overview_with_edge}
\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 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 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 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.
% TODO: privacy
@ -129,7 +129,7 @@ Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetni
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
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ő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.
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.
@ -137,7 +137,7 @@ A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a
\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.
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}.
A dolgozatom részeként a felhő és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
@ -150,7 +150,7 @@ A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket
\subsection{EdgeX Foundry}
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.
@ -169,7 +169,7 @@ Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a
\subsection{Project EVE}
A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. A \Gls{linux} alapokra épül, erre épülő operációs rendszerük neve az EVE-OS. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az EVE-OS jelenleg támogat Docker konténereket, virtuális gépeket és Kubernetes klasztereket, viszont utóbbi támogatása kezdetleges.
A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \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 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.
@ -182,17 +182,17 @@ A különböző backendek támogatása azzal jár, hogy ezeket egységes absztra
A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy specifikáció halmaz, amely igyekszik a peremhálózati rendszerek fejlesztése során gyakran felmerülő problémákra tervezési mintákat adni.
Ezek a specifikációk lefednek számos az peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.
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.
% TODO befejezni
\subsection{StarlingX}
%\subsection{StarlingX}
% TODO erről is írni valamit
\subsection{KubeEdge}
A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit peremhálózati rendszerek kezelésével\cite{kubeedge_docs}. Így lehetővé teszi a konténerizált alkalmazások futtatását a peremhálózaton. Architektúrája két részből épül fel, a központi felhőből és a peremhálózatól.
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.
@ -208,7 +208,7 @@ Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} egy az \textit{Amazon} ált
A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó szolgáltatások halmaza, a másik pedig a peremhálózati rendszerre telepíthető\footnote{Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} támogatja azt a megközelítést is ahol a peremhálózat maga a végeszközök rendszere. Ennek megfelelően a \enquote{kliens} alkalmazást oda is lehet telepíteni.} (itt átjáróként hivatkozott) \enquote{kliens} szoftver. Az \acrshort{iot} eszközök ezen az átjárón futó szoftverrel kommunikálnak. Az itt futó peremhálózati szolgáltatások pedig az interneten keresztül kommunikálnak az \acrshort{aws} felhőben futtatott többi komponenssel.
A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor azok a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
A 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
@ -217,7 +217,7 @@ A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében h
Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen bemutatása csak a teljesebb kép bemutatását szolgálja.
Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget az egyes eszközökön.
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.

78
src/content/ursim_impl.tex
View File

@ -4,65 +4,65 @@
\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 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 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 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.
Ez az alkalmazás a peremhálózati rendszerek alacsony késleltetését aknázza ki. Hiszen a robotika vezérlésnél fontos a precíz irányítás, úgy vélem itt különösen jól alkalmazható ez a technológia. A peremhálózati rendszereknek hála tovább csökkenthetővé válik a gyárakban helyben telepített informatikai infrastruktúra mértéke, hiszen több alkalmazás válik felhőbe \enquote{költöztethetővé} és ezáltal annak előnyeit is nagyobb mértékben lesznek képesek kihasználni a gyártósorok.
,
Ebben a feladatban egy már rendelkezésre álló demót alakítottam át úgy, hogy az kihasználja a peremhálózati rendszerek adta lehetőségeket.
\section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése
A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demó szcenárió, amely kifejezetten a hálózati késleltetés jelentőségének bemutatására lett tervezve. Ez a szcenárió magában foglalja mind a szoftveres és a hardveres megoldást. A kettőt összekötő hálózatot és még egyedileg 3D nyomtatott munkadarabokat is.
A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demó szcenárió, amely kifejezetten a hálózati késleltetés jelentőségének bemutatására lett tervezve. Ez a szcenárió magában foglalja mind a szoftveres és a hardveres megoldást, a kettőt összekötő hálózatot és még egyedileg 3D nyomtatott munkadarabokat is.
\subsection{\textit{Universal Robots}}
A demóban használt robotkarokat az \textit{Universal Robots} nevű dán vállalat tervezi és gyártja. A gyártó palettáján több robotkar is megtalálható. Ez az írás idejében kétszer négy 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 demóban használt robotkarokat az \textit{Universal Robots} nevű dán vállalat tervezi és gyártja. A gyártó palettáján több robotkar is megtalálható. Ez az írás idejében kétszer három plusz egy modellt jelent, az \textit{UR3} és \textit{UR3e}, az \textit{UR5} és \textit{UR5e}, az \textit{UR10} és \textit{UR10e} illetve az \textit{UR16e}. Mindegyik robotkar egyre növekvő módon egyre növekvő kihívásoknak képes eleget tenni. % TODO: Cite
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}.
Az \textit{Universal Robots} által gyártott robotkarok vezérlését a hozzákapcsolt \textit{Control Box} végzi. Ez lényegében egy Mini-ITX számítógép, ami egyéni \Gls{linux} alapú operációs rendszert futtat. Ezen a számítógépen fut a robotkarok alacsony szintű vezérlője, amelyet különböző hálózati protokollok segítéségével kezelhetünk, illetve a grafikus felület, amely lokális kapcsolaton csatlakozik ezekhez az interfészekhez \cite{urscriptreference}.
A demóhoz használt két robotkar típusa \textit{UR3} és \textit{UR3e}.
\subsubsection{Fizikai jellemzők}
Jellemzően többfajta felépítésű robotkar létezik. A demó során használt mindkettő robotkar csuklós felépítésű, azaz a 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 demó során használt mindkettő robotkar csuklós felépítésű, azaz az emberi karhoz hasonlóan hajlatokkal (joint) rendelkezik a merev tagok között.
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$\deg$ 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$ 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.
\subsubsection{Kommunikációs interfész}
Az demó által használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg\cite{robot_client_interfaces}:
Az demó által használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg \cite{robot_client_interfaces}:
\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 nagyjából 100ms gyakoriság).
\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).
\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz nagyjából 2ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt)\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 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 küldhetünk vagy fogadhatunk valamilyen információt) \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 a 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{\acrfull{rtde}}: Az \acrshort{rtde}-t egy robosztus 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}
Emellett a hozzákapcsolt grippereknek is lehet önálló kommunikációs interfésze. Míg az \textit{OnRobot RG2} csak a robotkarra kapcsolható közvetlen, így azt a fent említett kommunikációs protokollok segítségél, a robotkaron keresztül lehet vezérelni, az \textit{RG2-FT} lehetővé teszi, hogy közvetlenül a hálózatra csatlakoztassuk a grippert ezzel önálló módon kezeljük azt.
Emellett a hozzákapcsolt grippereknek is lehet önálló kommunikációs interfésze. Míg az \textit{OnRobot RG2} csak a robotkarra kapcsolható közvetlen, így azt a fent említett kommunikációs protokollok segítségél, a robotkaron keresztül lehet vezérelni, az \textit{RG2-FT} lehetővé teszi, hogy közvetlenül a hálózatra csatlakoztassuk a grippert, ezzel önálló módon kezeljük azt.
\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.
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 fő eltérés a pythonhoz 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 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.
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 az ütemezése a szálaknak 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 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.
A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást adni neki). 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} stílusban 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
\subsubsection{Szimulátor}
@ -75,7 +75,7 @@ Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy iz
\subsection{Demó}
A megvalósított demó egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemelnek egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi.
A megvalósított demó egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemel egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi.
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.
@ -83,7 +83,9 @@ A következőkben részletesen bemutatom a demó felépítését és működés
\subsubsection{Környezet}
A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. Két oldalt a két robotkar helyezkedik el. A robotkaroknak a szcenáriót tervező csapat találó módon az Erik és a Fred neveket adták. Az Erik nevezetű robotkaron található az \textit{rg2-ft} típusú gripper, amely önállóan csatlakozik a hálózatra, ezzel szemben a Fred nevezetű robotkaron lévő gripper a robotkar kommunikációs interfészén keresztül kapja az információt.
A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. Két oldalt a két robotkar helyezkedik el. A robotkaroknak a szcenáriót tervező csapat az Erik és a Fred neveket adták. Az Erik nevezetű robotkaron található az \textit{rg2-ft} típusú gripper, amely önállóan csatlakozik a hálózatra, ezzel szemben a Fred nevezetű robotkaron lévő gripper a robotkar kommunikációs interfészén keresztül kapja az információt.
Az asztalon a két munkadarabnak kijelölt helye van, ahonnan a robotkarok felemelik, az összeillesztés az asztal közepénél történik, majd valahol itt is helyezi el a kész darabot. A környezet vizuális bemutatásául \aref{fig:work_table}.\ ábra szolgál.
\begin{figure}[h!]
\centering
@ -92,35 +94,33 @@ A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre.
\label{fig:work_table}
\end{figure}
Az asztalon a két munkadarabnak kijelölt helye van, ahonnan a robotkarok felemelik, az összeillesztés az asztal közepénél történik, majd valahol itt is helyezi el a kész darabot. A környezet vizuális bemutatásául \aref{fig:work_table}.\ ábra szolgál.
\subsubsection{Vezérlés}
\label{sec:ursim_demo_control}
A demo vezérlésére a munkám elején egy monolit Python 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} apin keresztül végzi.
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.
A két robotkar vezérlése két külön szálon valósítja meg. 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 választani lehet a végrehajtás sebességét gyors és lassú között. Ez a robotkarok mozgási sebességét befolyásolja. Emellett lehetőség van \enquote{Jogging} módban 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á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 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 a koordináták mind tool- és joint térben. %TODO verify naming
\section{Tervezés} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
A fenti monolit demó felhő és perem számítástechnikai rendszerbe való átültetése úgy, hogy annak előnyeit megfelelően ki tudja használni alapos tervezést igényelt.
Alapos tervezést igényelt a fenti monolit demó átültetése egy felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
\subsection{Keretrendszer}
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-t választottam.
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-et választottam.
A kiválasztásának fő oka az volt, hogy támogatja a mikroszolgáltatás architektúrát, emellett -- a leírása alapján -- könnyen lehet alkalmazni, hiszen ha az alkalmazásunk konténerből futtatható, alig kell rajta módosítani, hiszen a \textit{KubeEdge} képes ezeket a konténereket beütemezni, hogy a peremhálózaton futhassanak. Így a korábban szerzett mikroszolgáltatás alapú alkalmazásfejlesztési tapasztalataimat itt könnyen tudtam hasznosítani.
Mindemellett \aref{sec:birbframework}.\ szekcióban kifejtettek alapján a másik alkalmazásomat is \textit{KubeEdge} alapokra építettem fel. Ennek köszönhetően a későbbi méréseimet is egyforma környezetben tudom végezni, ezzel egyszerűsítve azok implementációját amellett, hogy a két alkalmazáshoz nem kell két külön keretrendszert megismernem és fejleszteni rá.
A \textit{KubeEdge} használatának további előnye, hogy az általam már jól ismert \textit{Kubernetes} konténer orkesztációs platformra épül. Így a telepítése és megismerése számomra egyszerűbb.
A \textit{KubeEdge} használatának további előnye, hogy az általam már jól ismert \textit{Kubernetes} konténer orkesztációs platformra épül így a telepítése és megismerése számomra egyszerűbb.
\subsection{Architektúra}
@ -139,7 +139,7 @@ A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_servi
\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 telephelyet is vehetünk.
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}
\label{sec:edge_layer_plans}
@ -158,7 +158,7 @@ Mivel a legmagasabb réteg -- a felhő -- és a középső réteg között a kap
Mivel a peremhálózati rétegben már kialakítottunk egy absztrakciót, amely elfedi a késleltetési problémákat a felhő réteg elől, így a felhő rétegben futó szoftver ezt biztonságosan tudja használni a robotkar mozgatására.
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.
@ -180,7 +180,7 @@ Szerettem volna egy olyan végrehajtási környezetet megalkotni, ahol könnyen
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.
@ -193,7 +193,7 @@ Mivel itt már nem két szál összehangolásáról van szó hanem két egymá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.
Mivel fontos, hogy a szinkronizáció pontos legyen minden komponensnél, ezért annak az ötletét, hogy hálózaton küldött üzenetek szolgáljanak a szinkronizáció alapjául teljesen elvetettem.
Mivel fontos, hogy a szinkronizáció pontos legyen minden komponensnél, ezért annak az ötletét, hogy hálózaton küldött üzenetek szolgáljanak a szinkronizáció alapjául, teljesen elvetettem.
Ezzel szemben lehetőség van a futtató környezetet adó fizikai számítógépek óráinak meglepően precíz szinkronizációjára. \Aref{append:timesync}.\ függelékben ezt részletesebben is tárgyalom. Ezt alapul véve kidolgoztam egy kellően precíz szinkronizációs protokollt.
@ -212,14 +212,14 @@ A szinkronizációs folyamat időbeni lefutása \aref{fig:pyprocsync_flow} ábr
\label{fig:pyprocsync_flow}
\end{figure}
Az 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.
\subsubsection{Megfigyelés és vezérlés}
A szolgáltatásnak lehetőséget kell adni arra, hogy megfigyelhető és beavatkozható legyen a működése. 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ő és beavatkozható legyen. 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
@ -237,7 +237,7 @@ A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrs
Az architektúra, melyet \aref{sec:edge_layer_plans}.\ szekcióban bemutattam lehetővé teszi, hogy a felhőben futó komponensek bármilyen programot adjanak a peremhálózati réteg számára, legyen az automatikusan vagy részben automatikusan generált.
Mivel sem a demó sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
Mivel sem a demó, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
A szolgáltatásba fel lehet tölteni a felhasználó által megírt programot, illetve le lehet tölteni onnan egy egyszerű \acrshort{rest} \acrshort{api} használatával.
@ -245,7 +245,7 @@ A szolgáltatásba fel lehet tölteni a felhasználó által megírt programot,
Erre a komponensre is szintén azért van szükség, mert a felhőbe telepített komponenseket nem szerettem volna túlzottan bonyolulttá tenni.
Mivel a programok előre definiált formában léteznek, ezért kell egy komponens ami felel azért, hogy azoknak betöltését és végrehajtását elindítsa a peremhálózaton.
Mivel a programok előre definiált formában léteznek, ezért kell egy komponens, ami felel azért, hogy azoknak betöltését és végrehajtását elindítsa a peremhálózaton.
Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől és futtató környezettől. Az alapvető feladata az, hogy szükség esetén egy absztrakcióval szolgáljon a konkrét programfuttatási eljárás fölé egyszerű \acrshort{rest} \acrshort{api} kiszolgálásával.