diff --git a/src/content/acknowledgement.tex b/src/content/acknowledgement.tex index 77bc2a3..39342e4 100644 --- a/src/content/acknowledgement.tex +++ b/src/content/acknowledgement.tex @@ -2,4 +2,8 @@ %---------------------------------------------------------------------------- \chapter*{\koszonetnyilvanitas}\addcontentsline{toc}{chapter}{\koszonetnyilvanitas} %---------------------------------------------------------------------------- -Szeretném köszönetemet kifejezni konzulensemnek, Dr.~Maliosz~Markosznak, amiért lehetővé tette, hogy egy ilyen remek témán dolgozzak és emellett a rengeteg segítséget, amit Dr.~Simon~Csabával közösen adtak munkám során. \ No newline at end of file +Szeretném köszönetemet kifejezni konzulensemnek, Dr.~Maliosz~Markosznak, amiért lehetővé tette, hogy egy ilyen remek témán dolgozzak és emellett a rengeteg segítséget, amit Dr.~Simon~Csabával közösen adtak munkám során. + +Emellett köszönettel tartozom a Távközlési és Médiainformatikai Tanszék Nagysebességű Hálózatok Laboratóriumának (HSN LAB) és a Schönherz Kollégiumban található Schönherz Elektronikai Műhelynek (SEM), hogy biztosították számomra az eszközöket, szerszámokat és helyszínt a munkámhoz. + +Emellett szeretném megköszönni családomnak és barátaimnak a végtelen támogatást amit kaptam. \ No newline at end of file diff --git a/src/content/appendices.tex b/src/content/appendices.tex index 47936e0..c62039b 100644 --- a/src/content/appendices.tex +++ b/src/content/appendices.tex @@ -22,4 +22,9 @@ \end{itemize} +\section{Precíz időszinkronizáció} +\label{append:timesync} +... + +% NTP és PTP \ No newline at end of file diff --git a/src/content/birbnetes_impl.tex b/src/content/birbnetes_impl.tex index 51ce569..b03daa4 100644 --- a/src/content/birbnetes_impl.tex +++ b/src/content/birbnetes_impl.tex @@ -183,6 +183,9 @@ Emellett időnként szükség van \enquote{kis} adatok átvitelére mindkét ir \section{Tervezés} +\subsection{Keretrendszer} +\label{sec:birbframework} + % Itt leírom az átalakítást a három rétegű pörgő lófaszra % Még jó, hogy mikro meme, meg k8s, így tök véletlenül pont a kubeedge a legjobb framework hozzá diff --git a/src/content/overview.tex b/src/content/overview.tex index d6b5679..e1616a2 100644 --- a/src/content/overview.tex +++ b/src/content/overview.tex @@ -142,6 +142,7 @@ Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni 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. \section{Alkalmazás futtatási és fejlesztési keretrendszerek} +\label{sec:frameworks} % itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia diff --git a/src/content/ursim_impl.tex b/src/content/ursim_impl.tex index 68b8f76..2f43469 100644 --- a/src/content/ursim_impl.tex +++ b/src/content/ursim_impl.tex @@ -95,6 +95,7 @@ A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. 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. @@ -113,48 +114,154 @@ A fenti monolit demó felhő és perem számítástechnikai rendszerbe való át \subsection{Keretrendszer} -% Itt nagyon hosszan részletezem, hogy miért választottam a kube-edget +\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-t 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. \subsection{Architektúra} -% funkcionális felbontás +Mivel a \textit{KubeEdge}-t választottam az alkalmazásom felépítésére, így nagyon egyszerű volt annak a kérdésnek a megválaszolása, hogy milyen architektúrát használok a szoftver elkészítésére. Az alkalmazást mikroszolgáltatás architektúrára terveztem. + +Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demó vezérlést. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait. + +A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_services_plan-blocks}.\ ábra ad áttekintést. Érdemes megfigyelni, hogy végeredményében a három rétegű architektúránk egy három szintű robot vezérlést implementál, amely a vezérlési feladatokat egyre nagyobb absztrakcióval kezeli. Az egyes rétegeken belüli rendszerek tervezését a következő szekciókban ismertetem. \begin{figure}[h!] \centering \includegraphics[width=0.9\textwidth]{figures/ursim_services_plan-blocks} - \caption{} + \caption{Demó vezérlés felbontása funkcionális egységekre a futtatási környezet és a késleltetés igények szerint} \label{fig:usrsim_services_plan-blocks} \end{figure} -\subsection{\textit{Single Robot Controller}} +\subsubsection{\textit{On-site} réteg} -\subsection{Kiegészítő szolgáltatások} +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. + +\subsubsection{Peremhálózati réteg} +\label{sec:edge_layer_plans} + +A középső rétegben alacsony késleltetésünk van a robotkar felé, viszont csak limitált erőforrásaink vannak. Ennek érdekében csak azokat a komponenseket lenne érdemes ide tenni, amelynél ezek a szempontok fontosak és azt is minimálisan tartani. Ezen a szinten ezért egy \enquote{középszintű} vezérlő komponenst terveztem. Ez már az általam írt kód szerint dolgozik, így tetszőleges logikát tudok bele implementálni. Az alacsony késleltetés miatt innen megbízhatóan és közvetlenül lehet a robotkarnak mozgató utasításokat kiadni illetve az állapotát beolvasni. + +A \enquote{középszintű} vezérlés feladata egy olyan absztrakciót adni az egyel magasabb réteg felé, hogy ott már olyan módon lehessen irányítani a robotok működését, hogy azt ne zavarja a késleltetés. Ezt az absztrakciót úgy terveztem meg, hogy nagyobb, összefüggő lépés sorozatok végrehajtását tegye lehetővé a magasabb réteg felé. + +A lépés sorozatoknál elvárás, hogy biztonságos állapotból indulnak és biztonságos állapotba érkeznek. Így a kettő lépés sorozat végrehajtása között eltelt idő nem befolyásolja károsan a rendszert. A lépés sorozatok engednek egy bizonyos fokú külső befolyást is, viszont ezeket szigorúan úgy kell implementálni, hogy itt se számítson a késleltetése a beavatkozásoknak. + +A lépés 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. + +\subsubsection{Felhő réteg} + +Mivel a legmagasabb réteg -- a felhő -- és a középső réteg között a kapcsolat nem megbízható, előfordulhatnak magas, akár ingadozó késleltetések is, szélsőséges esetben a kapcsolat megszakadása, ezért ezt figyelembe véve ide olyan komponenseket lehet csak helyezni, amelyek erre nem érzékenyek. + +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 adatok gyűjtése nem késleltetés érzékeny, ezért nem okoz problémát, ha a peremhálózatról egyenesen a felhőbe küldjük. Mivel a dolgozatom a \textit{Big Data} konkrét elemzésére nem tér ki, ezért az általam tervezett rendszerben a mérési adatokkal való tervezés kimerül azok gyűjtésében. + +\subsection{\textit{Single Robot Controller}} % Peremhálózati rendszer basically + +\Aref{sec:edge_layer_plans}.\ szekcióban ismertetettek alapján terveztem meg a peremhálózati rendszerben futó mikroszolgáltatás halmazt. Jelenleg ez egyetlen egy mikroszolgáltatásból áll, ez az a szolgáltatás a \textit{program}ok futtatását valósítja meg. + +Egy program egyszerre csak egy robotkar működését írja le, így egy ilyen komponens egyszerre csak egy robotkarhoz kapcsolódik. A demó végrehajtásához két komponensnek kell kapcsolódnia. + +Emellett meg kell oldania olyan problémákat is, amelyek \aref{sec:ursim_demo_control}.\ szekcióban ismertetett programnál adottak -- vagy legalábbis közel-triviálisan megoldhatóak -- voltak. + +\subsubsection{Végrehajtási keretrendszer} + +Annak érdekében, hogy a komponens absztrakt módon megoldást adjon a késleltetések áthidalására a felhő és a peremhálózati rendszerek között a robot mozgatásához szükséges lépéseket egy \textit{program}ba szedve kapja meg. Egy ilyen \textit{program} utasításokból épül fel, amelyet interpretáltan, imperatív módon hajt végre a komponens. + +Szerettem volna egy olyan végrehajtási környezetet megalkotni, ahol könnyen lehet az egyes utasítások mögött cserélni a funkcionalitást. Ezzel egyrészt lehetőség nyílik arra, hogy a programokat szinte módosítás nélkül újrahasznosítsuk. + +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. + +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. + +\subsubsection{Szinkronizáció} + +A demó során kiemelt szerepe van a két robotkar lépéseinek összehangolására kritikus pontokban. + +Mivel itt már nem két szál összehangolásáról van szó hanem két egymástól független alkalmazásra, amelyek az architektúra, a peremhálózati keretrendszer és a futtatási környezetből adódóan jóformán csak hálózaton tudnak kommunikálni, ezért ez egy teljesen más megoldást kívánt. + +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. + +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. + +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. + +A \enquote{megegyezéshez} egy osztott in-memory adatbázist használtam, a \textit{Redis}\footnote{\url{https://redis.io/}}-t, amely nem csak hálózaton elérhető és atomicitást garantáló műveleteket biztosít, de beépítetten tartalmaz egy üzenetsort, amely alkalmas a folytatási idő kihirdetésére. + +% Itt ezt jó lenne még taglalni + +A szinkronizációs folyamat időbeni lefutása \aref{fig:pyprocsync_flow} ábrán látható (konkrét \textit{Redis} utasításokkal bemutatva). + +\begin{figure}[h!] + \centering + \includegraphics[width=1\textwidth]{figures/pyprocsync_flow} + \caption{Az általam tervezett szinkronizációs protokoll működése szekvencia diagramon ábrázolva} + \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. -% külön lehet írni a magas szintű tervezésről és egyes szoftverek architektúrájáról -% Itt le lehet írni a controller magas szintű terveit, plugin architektúrát +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. -% tervezés és a nehézségek nem tételesen de hasonlóan struktúrálva -% Illetve a komoly megoldásaim +\subsubsection{Megfigyelés és vezérlés} -% Kiemelve a szinkronizációs problémákat, illetve (korábban) leírva hogy pontosan milyen problémát is próbálok megoldani ezzel azaz mér van szükség rá +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. -% Ide valszeg be fog kerülni Máté Miklós munkájáról is egy kis írás +Azért ezt a megoldást választottam, mert a \acrshort{http} protokoll kellően elterjedt, ezért széleskörűen támogatott. Mivel a futtatókörnyezet \textit{Kubernetes} alapú, ezért ez a legkönnyebben kezelhető hálózati erőforrás. %TODO: alátámasztani/megindokolni + +Az \acrshort{api} két fontos és fix funkciót kell kiszolgáljon. Szükség esetén a program futását meg kell tudni szakítani (akár egy lépés végrehajtása közben is), emellett a program futásának állapotát is lekérhetővé teszi. + +A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrshort{api} használatával lehet elérni. Ennek segítségével meg lehet valósítani a \enquote{jogging} futtatást egy olyan \textit{plugin}nel ami minden fő lépés után meghívásra kerül és várakozik az endpoint meghívására. + +\subsection{Felhő szolgáltatások} + +% itt írok általánosságban azokról a cucmókról, ami a felhőbe kerül + + +\subsubsection{\textit{Program Service}} + +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. + +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. + +\subsubsection{\textit{Job Orchestrator Service}} + +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. + +Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől és futtató környezettől. Az alapvető feladata az, hogy szükség esetén egy absztrakcióval szolgáljon a konkrét programfuttatási eljárás fölé egyszerű \acrshort{rest} \acrshort{api} kiszolgálásával. + + +\subsubsection{\textit{Metrics Service}} + +A metrika gyűjtés tervezése és implementációja még hátra van. + +\section{Implementáció} + +Az összes általam választott szolgáltatást \gls{python} nyelven implementáltam le. Mivel népszerű programnyelv ezért mind a robotkarok vezérlésére, mind pedig a többi felhasználásra kész programozói könyvtárakkal rendelkezik, így ez egy kézenfekvő választás volt. % ha nagyon kevés oldal van, akkor itt tudok írni a fejlesztői környezetről is illetve a tesztelésről -% Szinkronizációs protokol lófasznál ne felejtsek el írni az NTP-ről és PTP-től - \begin{figure}[h!] \centering \includegraphics[width=1\textwidth]{figures/ursim_services_plan-clean} \caption{A tervezett mikroszolgáltatások a futtatási környezetük szerint csoportosítva} \label{fig:usrsim_services_plan-clean} \end{figure} - -\section{Implementáció} - % Hát itt kénytelen leszek kódot magyarázni szerintem % Redis @@ -169,7 +276,37 @@ A fenti monolit demó felhő és perem számítástechnikai rendszerbe való át % Tiny HTTP Szerver, endpointok felsorolása % Pluginok compilerekkel +% + % Esetleg pluginok felsorolással -% A programok felépítéséről is lehet írni \ No newline at end of file + + +\subsection{\textit{Single Robot Control} \textit{plugin}ek} + +% ITt lehet írni a compilerek , regisztráció és loginről + +\subsubsection{\textit{Sync Plugin}} + +\subsubsection{\textit{UR-RTDE Plugin}} + +\subsubsection{\textit{Wait Plugin}} + +\subsubsection{Egyebek} + +\begin{itemize} + \item \textbf{Log Plugin} + \item \textbf{Sleep} +\end{itemize} + + +\subsection{\textit{Program} formátum} + +% YAML és JSON +% Struktúra +% sémavalidációk +% A programok felépítéséről is lehet írni + +\section{Tesztelés} + diff --git a/src/figures/pyprocsync_flow.pdf b/src/figures/pyprocsync_flow.pdf new file mode 100644 index 0000000..a5db21c Binary files /dev/null and b/src/figures/pyprocsync_flow.pdf differ