Finishing touches

This commit is contained in:
Pünkösd Marcell 2021-12-19 19:22:44 +01:00
parent dc5a61248d
commit e93fbf2386
11 changed files with 31 additions and 29 deletions

View File

@ -1 +0,0 @@
<mxfile host="Electron" modified="2021-12-16T14:46:48.619Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/15.4.0 Chrome/91.0.4472.164 Electron/13.5.0 Safari/537.36" etag="qp3HgiJCdhmuGHKC34LV" version="15.4.0" type="device"><diagram id="J8_ke5wYCe2sDKy8mfWC" name="Page-1">7VhNc5swEP01zLSHZAAZbB9t7CSdxmmm7jTJqaMaBRQL5BEi2Pz6ChAGIn/QpC7pTC+29kkrs2/fSos14ATrSwZX/oy6iGim7q41MNFM0wa6+MyATQFYfaMAPIbdAqoBc5wiCUo/L8YuihoLOaWE41UTXNAwRAvewCBjNGkue6Sk+asr6CEFmC8gUdE77HJfooauVxNXCHu+/OmBJScCWC6WQORDlyY1CEw14DBKeTEK1g4iGXclL4XfxZ7Z7YMxFPJWDnfO6Eeiz/1L5+neOosvv8TPZ3KXZ0hiGfAFIr7mWNpQTkV8U3IRJTggMBTWWLohxtF67/MY2yiFOhANEGcbsaR06EtipDLMnrSTimezpNmvUbwFocytt927Cl8MJAO/w4YaM3KFHKRJGfepR0NIphU6ZjQOXZRtqwurWnNN6UqAhgCfEOcbqW0YcyognwdEzqI15vfSPRs/ZOPzviXNybo2N9mURigCzr3OTau0H+qTlV9ulY5FhFlY+/N2QCkRjdkCHVjXl0UKmYcO7qfvVgdDBHL83Hy6P57pvqL7meYAbWRE1MXL7KAozBRH2WA8EtDsWjNtImIa/2Ri5GWjD87NzUdFNJUksvwmPuZovoI5bYk4JZvpb1dKe1Oyt77sZnlZanUZ5o7qsk9WXLrC+WecszxkvPheirsjH0Tvk1KjSakhKq9bTk2F0lvEUOAX4s3JHINU1FO2UfjIYMRZvOSFpBk88QkPhsdPeGOwgy8DnIqwnkLYlETldde66OffZ50VvXmY8ndW9EDh+xP9lt0/UbrMObbTE4vQaiNC+6+2GZZCyhUMPVbw4aW5CCe845MQHGTVbJIKutaZrVD6FcMo5fJS/ydI7P46GSg8ddb+tux+jUbre77thN/Q/Grt+lyZq6N9bm+3BFq3ubnriDG4qS1YURzyqLbzbQbUDr3By/p88W54bH3zXVIMiieopLUN5fVqG/5XW2u19Vqqrf9Gtb2twze7zKjxmozqnWW0fJc4mlL7NCkVZvXfU1HS1R94YPoL</diagram></mxfile>

View File

@ -0,0 +1 @@
<mxfile host="Electron" modified="2021-12-19T17:57:45.432Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/15.4.0 Chrome/91.0.4472.164 Electron/13.5.0 Safari/537.36" etag="rK7NgbXAnSxpK_ole-oy" version="15.4.0" type="device" pages="2"><diagram id="J8_ke5wYCe2sDKy8mfWC" name="Page-1">7Vlbc6IwFP41PHYHCHh5VLS23e1sp+5O233pZCSFKBAnxBu/foMEw03Etup2Zp/M+XISku98nByiAix/PaJw7t4TG3mKrtprBQwUXdc0Vec/MbJJkHa3lQAOxbZwksAYR0iAqkAX2EZhzpER4jE8z4MTEgRownIYpJSs8m5vxMs/dQ4dVALGE+iV0SdsM3e3L1V23CDsuOLRHVN0+DB1FkDoQpusMhAYKsCihLCk5a8t5MXkpbwk46739O4WRlHAGg14snqvK3Xsjqzps3m1GP1cLK9EdJbQW4gNPyCKfFexgNLTvPinDyLIcDxR8EZhyOhixrZ4j0KxM7ZJ6QpX2PdgwK3+GwmYiKcGuF1er9jCElGG1hlIrH+EiI8Y3XAX0Qu6gkshJt0Q9ioTmo7A3ExUNCBAKOTg7OaWjPGGIO0IAo0SgUMvVCxT6fKtqPe3seYSMiMcluiiZBHYKJ5f4wytXMzQeA4nce+Kv08cc5nvie4GhNaFuDnLeZLNCo71Co5bp6IYlCi+Jb84gMJothViKzqzDs0mOmxVcKSrpyLJLJF0AwOHJvw40VaCg+172+teRofgWJb1PMng0jpslSh+xDCMElK1r0mqppsXZrVT4g3Z/AQWJqHMJQ4JoDeUaF8yq3JL+vwgZC74nCLGNoJQuGAkzzZaY/Yshsftl7j9zRTWYJ3pGmxSI+DbfU4niI3MqNiUw7ZWOq5x/gnJgk5QDVUiVAxSB9WJQpxJMY+1kqDI4yf7Ml/pVAV4O7RHKdxkHOYEByzMzPwQA5kk2Sm+v4X65JB/vp7hjWQFUmq7rbxffd3/6muqPqOsvrtwOZ6q89+a6k7+3L1GuG+ZJ1JfSS7ArJbLbopkoWKU1NGxMgb1sjzs3zZPL2NNv6SOtffoWD2Djiv12TSLts6kY7Wgl66ZnyLZ0Id1bBR0aRhmrY6L/um6PkvHlbFJK3FZYl0jz00/p/bX+CGPZioPsF8upTKpQkF7KydNPVz06+2qot8oRLRCFI9owni9zrcmn1f4DtMrSjWz4nFGIQ9CjyEaQIb68fselgq2TwjbRbNP/hRtN00/MuO85BLOMemnkBvyaqoT+MEk1fSwNT+Yk5qW7pUPB/9O2PX3hV37omFvXTLs5Suve/EJTGw8O8+t14FMvj8Ie9N74UpHU8/4YVxXp2Ro/o6T+xsq7nFmyDvhhc7nU1y8e2hfmuLyjU7PhszZxAVHX5vK6zJVtpCH/Ogr0w5Oxzo35f8ZSXEh/xUCw78=</diagram><diagram id="59lvk3lC09troKBGTEtV" name="Page-2">1Vhdc6IwFP01PG6HQIH6WK3ddnb70NqZ3T5m5BZiA3FDLMqv3yCJAbF+dGzFJ7mH5Iack+RcY7mDZP6T42n8wEKglmOHc8u9sRwHIduRPyWyqJCg51dAxEmoGhlgRApQoK3QGQkhazQUjFFBpk1wzNIUxqKBYc5Z3mz2ymhz1CmOoAWMxpi20T8kFHGFXnm2we+ARLFYTVi9SbBurIAsxiHLa5A7tNwBZ0xUT8l8ALQkT/OSEjZxHsnzqHj00bS4muT/4EeV7PaQLqspcEjFcVMrcd8xnSm+7tmzBCAr3qyBa/X9Qk1eLDSjWU4SilMZ9TOBuVCau7YEXlmqY+TKWKUHLmC+pseOyaAVw3JpAktA8IXsp7Jcav3UqnQcr4pzo7HjqzZxTV/ZU60tta6iVe7VcE9yHeI0kvM1412ujRfYrfG8DcPpbno0TAXwFAvos1kaZnXB5ENtpgZayniApG5L0iHNrIFn9SSl9sN9uYlKaa9RQbKWuLz8LijzIylfHhMBoykel29zeUBILBYJVa+Pp7azVW2nST6y22IjZwP7vv2x1g3aD+X4ssUbhPLUUSHjImYRSzEdGrRvmC03imnzm7Gp4nMCQiwUoXgmWJNtmBPxt+x+4anopfbmZq4yL4OFDlI53b+6WRm8mAxlaLotI91vs7LlJD+hqySKzfgYtrRTgsrjJIJt+dzN64QDxYK8Nz/u6Kp7rZ11J48JXp2TUbHcVDdi+dM7k52F1raWe+qd5bc4fiI4KypW0ZmyioJT0xq0aL0FGmtX6KDBo3XD3WTwwfEMHrm7x+uIwV+d1Hxq1mNfBN5+7lMznJeG33yt+wR7uo/+r7LTftAHi/Z7/KfXHeGdzwmPzlb4Dw787xFef2bt+H5QhshC8tbdsj7Yesb3ulbWI9Ti+Rep6jmu6ro3oB0r8LZz3LlKBLWvHK5DLKJFWYz00cTUz7Z5AgpJcc68n7yuRm53zGO7dxzLA3Rdu8sD3H0twN4s+DdZwEmvHNAB+hnvP82Vw76668N+p/D+1+guQ3N3XP03MDfw7vA/</diagram></mxfile>

View File

@ -10,13 +10,13 @@
\chapter*{Kivonat}\addcontentsline{toc}{chapter}{Kivonat}
Napjainkban szinte alapvetőnek tekinthetők a felhőben üzemeltetett alkalmazások. Évről évre egyre nagyobb adoptációt érnek el, de mégis vannak még olyan területek, ahol még várat magára, hogy szélesebb körben is alkalmazzák. Ilyen területnek számítanak azok az alkalmazások, ahol a hálózati késleltetés egy kritikus tényező, vagy éppen a megfelelő sávszélesség nem áll rendelkezésre vagy túl költséges lenne a felhasználás helye és a felhő között.
Napjainkban szinte alapvetőnek tekinthetők a felhőben üzemeltetett alkalmazások. Évről évre egyre nagyobb adoptációt érnek el, de mégis vannak olyan területek, ahol még várat magára, hogy szélesebb körben is alkalmazzák. Ilyen területnek számítanak azok az alkalmazások, ahol a hálózati késleltetés egy kritikus tényező, vagy éppen a megfelelő sávszélesség nem áll rendelkezésre vagy túl költséges lenne a felhasználás helye és a felhő között.
Ilyen és ehhez hasonló problémákra adhat megoldást a peremhálózati infrastruktúra használata. A megfelelő alkalmazások a peremhálózati infrastruktúra lehetőségeivel kiegészítve képesek lehetnek egyes komponensekkel csökkentett késleltetéssel és kedvezőbb sávszélesség feltételekkel kommunikálni.
Peremhálózati rendszerek alkalmazásának rengeteg előnye ellenére még kevés olyan alkalmazás van, amely teljesen ki tudja használni azokat. Ennek oka az, hogy lévén viszonylag újkeletű technológia, még számos kérdés megoldatlan vele kapcsolatban.
A dolgozat célja, hogy konkrét alkalmazásokon keresztül mutassa be a azt, miképp lehet ezeknek a kérdéseknek egy részét megválaszolni és így sikeresen kihasználni a a peremhálózati infrastruktúra adta lehetőségeket, ezzel segítve ezen rendszerek adoptációjának további fejlődését.
A dolgozat célja, hogy konkrét alkalmazásokon keresztül mutassa be a azt, miképp lehet ezeknek a kérdéseknek egy részét megválaszolni és így sikeresen kihasználni a peremhálózati infrastruktúra adta lehetőségeket, ezzel segítve ezen rendszerek adoptációjának további fejlődését.
A dolgozat első részében rövid áttekintést nyújt a felhő és a peremhálózati infrastruktúrák felépítésébe és működésébe. Bemutat néhány lehetséges keretrendszert, amelyek segítségével megoldható a peremhálózati infrastruktúra bevonása az alkalmazásunkba. Ezekből egyet kiválasztva mutatja be a peremhálózati szolgáltatás létesítését két konkrét alkalmazáson keresztül.

View File

@ -8,7 +8,7 @@
A rendszer eredetileg a szőlővidékre telepített \acrfull{iot} eszközökből és a felhőben futó szoftverből áll. Kétszintű mesterséges intelligencia segítségével mind az eszközök, mind a felhő szoftver végez intelligens felismerést. Az eszköz maga egy egyszerűbb algoritmussal próbálja megállapítani, hogy a rögzített hangminta tartalmaz-e madárcsiripelést. Ha igen, továbbítja a mintát a felhőbe, ahol egy komolyabb számítási igényű mesterséges intelligencia osztályozza a mintát aszerint, hogy milyen madár hangját tartalmazza a minta. Ha a felismerés eredménye arra utal, hogy a cél madár hangját sikerült rögzíteni, akkor a rendszer megpróbálkozik a kérdéses madár elriasztásával hangminták lejátszásával a területen telepített eszközön.
A rendszer belső működéséről egy rövid összefoglaló található \aref{appendix:birbnetes}.\ függelékben. A fejezeten belül csak a permhálózati alkalmazásra való átalakítás szempontjából érintett részleteket vázolom.
A rendszer belső működéséről egy rövid összefoglaló található \aref{appendix:birbnetes}.\ függelékben. Ezen fejezeten belül csak a permhálózati alkalmazásra való átalakítás szempontjából érintett részleteket vázolom.
Ez az alkalmazás a peremhálózati rendszerek adat aggregációs lehetőségeit hivatott kiaknázni. Azzal, hogy bevonjuk a peremhálózati rendszereket a működésbe, jelentős adatforgalmi és számítási kapacitásbeli megtakarításokat érhetünk el.

View File

@ -156,4 +156,6 @@
\newacronym{oci}{OCI}{Open Container Initiative}
\newacronym{raid}{RAID}{Redundant Array of Independent Disks}
\newacronym{ssd}{SSD}{Solid State Drive}
\newacronym{icmp}{ICMP}{Internet Control Message Protocol}
\newacronym{icmp}{ICMP}{Internet Control Message Protocol}
\newacronym{ntp}{NTP}{Network Time Protocol}
\newacronym{ptp}{PTP}{Precision Time Protocol}

View File

@ -58,7 +58,7 @@ Emellett feltűnő volt, hogy a rendszer nagyon lassan reagál a terhelésre és
\subsection{Környezet}
Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ alfejezetben ismertetett ütemező szoftver metrika gyűjtő komponenseit is, mivel itt nem volt szükség az ott ismertetett ütemező futtatására.
Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ alfejezetben ismertetett ütemező szoftver metrika gyűjtő komponenseit is, mivel itt nem volt szükség az ott ismertetett ütemező futtatására. Meggyőződtem arról, hogy a pontos szinkronizáció eléréséhez, összes virtuális gépen helyesen jár a rendszer óra \acrshort{ntp} protokoll beállításával.
A robotkarok szimulálására \aref{sec:ursim_simulator}.\ alfejezetben ismertetett \textit{DockURSim} szoftvert futtattam két példányban. Mivel a vezérlő szolgáltatások \acrshort{ip} cím alapján kapcsolódnak az egyes robotkarokhoz, így a klienseket emuláló virtuális gépnek felvettem két \acrshort{ip} címet, az egyik szimulátor portjait az egyik címhez a másikat a másikhoz rendeltem. Így képes voltam két robotkar szimulálására.

View File

@ -72,7 +72,7 @@ Az egységek fejlesztése és tesztelése sokkal gyorsabb ütemben tud haladni a
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 \acrshort{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
\label{sec:peremhalozati_rendszerek}
@ -94,7 +94,7 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
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}}\footnote{\url{https://www.lfedge.org/openglossary/}} néven. 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}
@ -150,7 +150,7 @@ Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek
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 két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken 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.
A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demonstrálhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
\label{sec:frameworks}
@ -159,7 +159,7 @@ Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati k
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.
\subsection{EdgeX Foundry}
@ -178,7 +178,7 @@ A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
\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}
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 további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.
% TODO: Savazni
@ -206,11 +206,11 @@ Lévén ezek csak specifikációk és tervrajzok, az egyes kiadások nem szoftve
\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{Kubernetesre} é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 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. Illetve 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.
Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel. Ahhoz, hogy ezt megoldja, a \textit{Kubernetes} klaszteren belül használt hálózati plugin segítségével kiterjeszti és összekapcsolja a \textit{Pod} hálózatot.

View File

@ -46,7 +46,7 @@ Az demonstráción használt \textit{Universal Robots} robotkarok többféle kom
\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 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{\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{URScriptet} 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).
\end{itemize}
@ -69,7 +69,7 @@ A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást
A tanszéken található kettő robotkar természetesen nem áll mindig rendelkezésre. Más csapatok más-más projektekben is használják. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a projekten korábban dolgozó csapat által. Végül a leghatékonyabban használhatónak a \textit{DockURSim}\footnote{\url{https://github.com/ahobsonsayers/DockURSim}} bizonyult.
Lényegében a \textit{DockURSim} a robotkarokat közvetlenül irányító, \textit{Control Box}on futó szoftver becsomagolva egy \textit{Docker} konténerbe. Konkrét robotkart nem irányít, de a kommunikációs interfészeket és azok funkcionalitását teljes mértékben implementálja. Lehetőségünk van a beépített \acrfull{rdp} szerveren keresztül grafikus felületet\footnote{Ez a grafikus felület a \textit{Teach Pendant}on grafikusan kezelhető felület.} kezelni és ott meg tudjuk figyelni a robotkar mozgását.
Lényegében a \textit{DockURSim} a robotkarokat közvetlenül irányító, \textit{Control Boxon} futó szoftver becsomagolva egy \textit{Docker} konténerbe. Konkrét robotkart nem irányít, de a kommunikációs interfészeket és azok funkcionalitását teljes mértékben implementálja. Lehetőségünk van a beépített \acrfull{rdp} szerveren keresztül grafikus felületet\footnote{Ez a grafikus felület a \textit{Teach Pendanton} grafikusan kezelhető felület.} kezelni és ott meg tudjuk figyelni a robotkar mozgását.
Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy izolált környezetben tudja csak szimulálni, így a környezet fizikai hatásai, a gripperek működése és a robotkarok egymással való találkozását nem képes modellezni.
@ -102,7 +102,7 @@ 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 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 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 felderíté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.
@ -140,7 +140,7 @@ A \enquote{középszintű} vezérlés feladata egy olyan absztrakciót adni az e
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{Programnak} 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.
\subsubsection{Felhő réteg}
@ -155,7 +155,7 @@ Az adatok gyűjtése nem késleltetés érzékeny, ezért nem okoz problémát,
\subsection{Peremhálózati szolgáltatások} % Peremhálózati rendszer basically
\label{sec:single_robot_contoller_plans}
\Aref{sec:edge_layer_plans}.\ alfejezetben 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.
\Aref{sec:edge_layer_plans}.\ alfejezetben 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{programok} 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.
@ -164,7 +164,7 @@ Emellett meg kell oldania olyan problémákat is, amelyek \aref{sec:ursim_demo_c
\subsubsection{Végrehajtási keretrendszer}
\label{sec:ursim_execution_framework}
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{programba} 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 lehetőség nyílik arra, hogy a programokat szinte módosítás nélkül újrahasznosítsuk.
@ -185,7 +185,7 @@ Alapos kutatás után sajnos nem találtam erre a problémára teljes, kész meg
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.
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 Hálózati idő protokoll (\acrlong{ntp}; \acrshort{ntp}) vagy Precíz idő protokoll (\acrlong{ptp}; \acrshort{ptp}) használatával. Ezt alapul véve kidolgoztam egy megfelelően precíz szinkronizációs protokollt.
Szinkronizáció gyanánt a résztvevők (Az egyes \textit{Single Robot Controller} példányok) \enquote{megegyeznek} abban, hogy mikor lesz az az időpont, amikor tovább haladnak a végrehajtással. Ehhez szükség van arra, hogy megbizonyosodjanak róla, hogy minden szolgáltatás elért a végrehajtással arra a pontra, ahonnan csak együtt léphetnek tovább.
@ -215,7 +215,7 @@ Azért ezt a megoldást választottam, mert a \acrshort{http} protokoll kellően
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{pluginek} 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{pluginnel}, 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}
\label{sec:cloud_layer_plans}
@ -227,7 +227,7 @@ A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrs
Az architektúra, melyet \aref{sec:edge_layer_plans}.\ alfejezetben 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 demonstráció, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
Mivel sem a demonstráció, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{programok} 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.
@ -289,15 +289,15 @@ A \textit{Program Service} esetén az eltárolt programokat egy dokumentum tárb
% Esetleg pluginok felsorolással
\subsection{\textit{Single Robot Control} \textit{plugin}ek}
\subsection{\textit{Single Robot Control} \textit{pluginek}}
A \textit{Single Robot Control} komponens által, a \textit{programban} definiált utasítások implementációjára \textit{plugin}ek a programban osztályok csoportjaként kerültek megvalósításra.
A \textit{Single Robot Control} komponens által, a \textit{programban} definiált utasítások implementációjára \textit{pluginek} a programban osztályok csoportjaként kerültek megvalósításra.
Minden \textit{plugin} egy különálló osztályban van megvalósítva. Ennek példányosításával lefut az adott \textit{plugin} inicializációja (például: csatlakozás a robotkarokhoz), majd regisztrálja a rendelkezésre álló utasítás osztályokat. A \textit{plugin} osztályok implementálnak egy \texttt{close} függvényt is, amely a foglalt erőforrások felszabadításáért felel.
A beregisztrált utasítás osztályok lényegében egy \textit{factory} mintát valósítanak meg. Amikor a szolgáltatás betölt egy \textit{programot} akkor először minden lépését értelmezi azzal, hogy ezekkel a \textit{factory} osztályokkal példányosítja a konkrét utasítás objektumot. Ezen a ponton lehetőség van a bevitt adatok helyességének ellenőrzésére, hogy ez ne a futtatáskor történjen meg, ezzel futtatás közben spórolva a \acrshort{cpu} ciklusokkal és \textit{fail-early} megközelítés szerint még az előtt kiderülnek a problémák, hogy a program futtatásra kerülne.
Az értelmezett utasításokat listába szervezve készíti elő a futtatható \textit{program}ot a szolgáltatás. Ezek a példányosított utasítások implementálják \aref{sec:ursim_execution_framework}.\ alfejezetben említett három fő funkciót: \texttt{execute}, \texttt{abort} és \texttt{describe}. Az egyes paraméterek összerendelése ebben a lépésben történik meg az utasításokhoz.
Az értelmezett utasításokat listába szervezve készíti elő a futtatható \textit{programot} a szolgáltatás. Ezek a példányosított utasítások implementálják \aref{sec:ursim_execution_framework}.\ alfejezetben említett három fő funkciót: \texttt{execute}, \texttt{abort} és \texttt{describe}. Az egyes paraméterek összerendelése ebben a lépésben történik meg az utasításokhoz.
Amikor egy program futtatásra kerül, akkor a komponens egyesével lépkedve a listán minden elemnek meghívja az \texttt{execute} függvényét. Ha meg kell szakítani a futást, akkor az éppen futó lépes \texttt{abort} függvényét meghívva, leállítja azt, és a következő parancsot már nem hajtja végre.
@ -331,10 +331,10 @@ Ennek a pluginnek a használatával megvalósítható, a demonstráció során i
\subsubsection{Egyebek}
A fent vázolt \textit{plugin}ek mellett készítettem néhány egyszerűbbet is, amelyek egyszerűbb vagy csak hibakeresésnél használatos funkciókat implementálnak:
A fent vázolt \textit{pluginek} mellett készítettem néhány egyszerűbbet is, amelyek egyszerűbb vagy csak hibakeresésnél használatos funkciókat implementálnak:
\begin{itemize}
\item \textbf{Log Plugin} Ezzel a \textit{plugin}nel a program futása közben előre definiált üzeneteket jeleníthetünk meg az alkalmazás naplójában.
\item \textbf{Log Plugin} Ezzel a \textit{pluginnel} a program futása közben előre definiált üzeneteket jeleníthetünk meg az alkalmazás naplójában.
\item \textbf{Sleep} Ez a \textit{plugin} lehetővé teszi hogy meghatározott ideig szüneteltessük a végrehajtást.
\end{itemize}
@ -345,7 +345,7 @@ A robotkarok vezérlésének lépései az általam tervezett formátumú \textit
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 is.
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{pluginek} 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.
@ -379,7 +379,7 @@ program:
acceleration: 0.75
\end{lstlisting}
A program sémájának validálására a \textit{Marshmallow}\footnote{\url{https://github.com/marshmallow-code/marshmallow}} könyvtárat használtam. Ezzel deklaratív módon tudtam validációs sémákat írni, amelyet minden komponensnél használtam, amely érintkezik valamilyen szinten \textit{program}okkal. Így a lehető leghamarabb vissza tudja utasítani a rendszer a hibás programokat.
A program sémájának validálására a \textit{Marshmallow}\footnote{\url{https://github.com/marshmallow-code/marshmallow}} könyvtárat használtam. Ezzel deklaratív módon tudtam validációs sémákat írni, amelyet minden komponensnél használtam, amely érintkezik valamilyen szinten \textit{programokkal}. Így a lehető leghamarabb vissza tudja utasítani a rendszer a hibás programokat.
Az eredeti szoftver által vezérelt mozgást futás időben fordítottam le az általam definiált \textit{program} struktúrára azáltal, hogy a program kódjában a \gls{python} által biztosított reflexiókat használva, az egyes lépéseket lecseréltem fájlba mentő funkciókra amely rögzíti az utasításokat és a paramétereiket.