diplomová práce

Vzdálené volání procedur přes TCP protokol v prostředí vestavěných systémů

Text práce 2.87 MB

Autor práce: Ing. Andrej Hýroš

Ak. rok: 2024/2025

Vedoucí: Ing. Václav Šimek

Oponent: Ing. Josef Strnadel, Ph.D.

Abstrakt:

Táto práca sa zaoberá návrhom a implementáciou transportnej vrstvy pre medzivrstvu eRPC vyvinutú spoločnosťou NXP za použitia technológie LwIP. LwIP je malá a efektívna implementácia sieťových vrstiev TCP/IP, vďaka čomu je populárna na vstavaných systémoch s obmedzenými zdrojmi. Výsledkom je obohatenie medzivrstvy eRPC o možnosť prenášať potrebné dáta s malými pamäťovými nárokmi práve technológiou LwIP. Súčasťou práce je taktiež vytvorenie demonštračného príkladu, ktorý bude dostupný na platforme GitHub pod licenciou Apache.

Klíčová slova:

LwIP, eRPC, vzdialené volanie procedúr, TCP/IP, vstavané systémy, MIMXRT1060, Zephyr, SysTick, socket, mbedTLS

Termín obhajoby

25.06.2025

Výsledek obhajoby

obhájeno (práce byla úspěšně obhájena)

znamkaCznamka

Klasifikace

C

Průběh obhajoby

Student nejprve prezentoval výsledky, kterých dosáhl v rámci své práce. Komise se poté seznámila s hodnocením vedoucího a posudkem oponenta práce. Student následně odpověděl na otázky oponenta a na další otázky přítomných. Komise se na základě posudku oponenta, hodnocení vedoucího, přednesené prezentace a odpovědí studenta na položené otázky rozhodla práci hodnotit stupněm C.

Otázky k obhajobě

  1. Stručně objasněte mechanismus, který jste použil pro nastavení hodnot uvedených v Tab. 5.1 (str. 33) a Tab. 5.2 (str. 43).
  2. Proč jste implementoval jen dynamickou a ne také statickou politiku přidělování prostředků v eRPC (konec části 5.3, str. 35)?
  3. Proč je v baremetal aplikacích založených na lwIP od NXP (viz konec prvního odstavce na str. 42) problém využít přerušení?
  4. Na jak dlouho může být zařízení zablokováno obsluhou přerušení?
  5. Co je hlavním přínosem vaší práce? Prováděl jste kromě integrace také systémové testy?
  6. Popisujete v práci průběh volání?

Jazyk práce

angličtina

Fakulta

Fakulta informačních technologií

Ústav

Ústav počítačových systémů

Studijní program

Informační technologie a umělá inteligence (MITAI)

Specializace

Softwarové inženýrství (NSEN)

Složení komise

doc. RNDr. Pavel Smrž, Ph.D. (předseda)
doc. RNDr. Jitka Kreslíková, CSc. (člen)
doc. Ing. Petr Matoušek, Ph.D., M.A. (člen)
Ing. Vladimír Bartík, Ph.D. (člen)
Ing. Aleš Smrčka, Ph.D. (člen)
Ing. Vojtěch Mrázek, Ph.D. (člen)

Posudek vedoucího
Ing. Václav Šimek

I když tento aspekt úplně nepřísluší hodnotit z pozice vedoucího, dovolil bych si vyslovit přesvědčení, že došlo ke vzniku velmi zdařilého díla bez problémů naplňujícího požadavky zadání. Vše je navíc podrobně zdokumentováno, což ostatně koresponduje s pečlivým přístupem studenta k řešení tohoto projektu. S ohledem na tyto skutečnosti tedy navrhuji souhrnné hodnocení stupněm A - výborně, 90 bodů.

Kritérium hodnocení Slovní hodnocení
Informace k zadání

Zadání této diplomové práce spadá do oblasti vestavěných systémů a síťových komunikací. Kromě toho se jedná o tzv. firemní zadání vypsané ve spolupráci se společností NXP.

Realizační výstup pak zahrnuje implementaci firmware a provedení experimentů na cílové MCU architektuře spolu s jejich vyhodnocením dle požadavků zadání. Klíčová část tohoto projektu má tedy implementační charakter. Domnívám se, že požadavky plynoucí z jednotlivých bodů zadání byly v úplnosti splněny.
Aktivita při dokončování

Dokončení realizačního výstupu i technické zprávy proběhlo s předstihem oproti stanovenému termínu. Bylo tudíž možné provést několik revizí technické zprávy, kdy se na straně studenta podařilo do podoby technické zprávy zapracovat prakticky všechny připomínky vedoucího.
Publikační činnost, ocenění

V souvislosti s řešením projektu mi není známa další publikační činnost nebo zisk souvisejících ocenění.
Práce s literaturou

V počátečním období řešení projektu bylo studentovi doporučeno několik informačních zdrojů, zbývající si pak aktivně dohledal již ve vlastní režii. Konečný výběr literatury byl konzultován. Domnívám se, že jednotlivé informační zdroje mají svoje opodstatnění a jsou v kontextu projektu řádně použity.
Aktivita během řešení, konzultace, komunikace

V průběhu celého období řešení projektu byla vzájemná komunikace na výborné úrovni, kdy student pravidelně sdílel informaci o aktuálním řešení projektu doplněné o výhled na nejbližší období. Prezenční konzultace byly svolávány minimálně a prakticky veškeré záležitosti bylo možno řešit prostředky vzdálené komunikace. Svůj přístup k řešení student taktéž pravidelně konzultoval s technickém vedoucím v rámci společnosti NXP. 
Výsledný počet bodů navržený vedoucím: 90

Známka navržená vedoucím: A

Posudek oponenta
Ing. Josef Strnadel, Ph.D.

Výsledek práce studenta (tj., realizační výstup a technickou zprávu) souhrnně považuji za průměrně kvalitní a, bez znalosti odpovědí na otázky z části Otázky k obhajobě, navrhuji ohodnotit jej stupněm C, jelikož (detaily viz výše):



  • zadání považuji za středně náročné,

  • i přes výše uvedené výtky hodnotím realizační výstup jako průměrně kvalitní, funkční dle požadavků zadání a jako průměrně kvalitně zdokumentovaný.

Kritérium hodnocení Slovní hodnocení Body
Rozsah splnění požadavků zadání

Stupeň hodnocení: zadání splněno

Domnívám se, že se stěžejními požadavky, zmiňovanými výše v části Náročnost zadání, se autor vypořádal přijatelným způsobem - zadání proto považuji za splněné.
Rozsah technické zprávy

Stupeň hodnocení: je v obvyklém rozmezí

Rozsah technické zprávy (TZ) považuji za obvyklý, jelikož TZ obsahuje veškeré podstatné informace k řešené problematice i k realizačnímu výstupu (RV).
Prezentační úroveň technické zprávy
  • Technická zpráva (TZ), psaná v angličtině, je vhodně strukturovaná, její části na sebe vhodně navazují a přispívají k její velmi dobré čitelnosti i představě o prostředcích, způsobu a výsledku řešení.
  • Z hlediska čitelnosti bych TZ vytkl nepřesnosti popř. nejasnosti ohledně některých doprovodných ilustrací (např. objasňující ukázka k multicast/broadcast v Fig. 2.5, výpis List. 3.1 s nejasným významem ethernetif a rxFrame, použití underlyingReceive v obou odrážkách na konci části 5.5.2 na str. 45, nadbytečnost Fig. 6.2) či, v části 6.2, absenci shrnutí výsledků testování a popisu řešení testováním zjištěných problémů. Některé skutečnosti nevyjasněné po přečtení TZ dávám k objasnění v části Otázky k obhajobě.
  • Souhrnně nemám k prezentační úrovni TZ vážnější výhrady a hodnotím ji jako podprůměrně kvalitní.
 69
Formální úprava technické zprávy
  • Technická zpráva (TZ) je sice psána v angličtině, avšak v ní přítomný rozšířený abstrakt (ve slovenštině), cca o rozsahu 1,4 normostrany, je pod spodní hranicí (2 normostrany) požadavku příslušných předpisů, tj. dle Směrnice rektora č. 72/2017 (čl. 3, odst. 7 a čl. 15, odst. 1e) a dle Směrnice děkana č. 7/2018 (čl. VI, odst. 5) v jejich aktuálním znění.
  • Úroveň typografické a jazykové stránky TZ považuji souhrnně za průměrně kvalitní - TZ obsahuje občasné jazykové nedostatky, většinou překlepy a chybějící ne/určité členy, z typografického hlediska TZ vytýkám poměrně častá "bílá místa" v textu.
 70
Práce s literaturou

Informační zdroje použité v technické zprávě jsou, vzhledem k tématu a zadání práce, vhodně zvoleny, pokrývají problematiku řešenou v rámci práce a v technické zprávě je na ně odkazováno způsobem umožňujícím řádné odlišení prvků vlastních od převzatých.

 90
Realizační výstup
  • Zadáním požadovaný realizační výstup (RV) je čistě softwarového charakteru, implementovaný převážně v C/C++ (zadáním požadovaná transportní vrstva nad lwIP pro eRPC) a částečně v Python (eRPC client/server), týkající se integrace eRPC a lwIP TCP stack vč. řešení spolehlivé a zabezpečené komunikace a otestování (viz třetí odrážka shora v části Náročnost zadání) výsledného řešení. 
  • Realizace je sice poměrně kvalitně zdokumentována v kapitolách 4 a 5 technické zprávy (TZ) a uspokojivě zhodnocena v kapitole 6 TZ, nicméně nadto bych uvítal detailnější dokumentaci generovanou např. pomocí Doxygen.
  • Souhrnně považuji RV za zdařilý a prakticky využitelný a, až na spíše okrajovou výtku týkající se otestování implementace v prostředí Zephyr (viz výše), také za splňující požadavky zadání.
 75
Využitelnost výsledků

Z technické zprávy plyne, že výsledek práce plánuje být využit firmou NXP Semiconductors Czech Republic, s.r.o.
Náročnost zadání

Stupeň hodnocení: průměrně obtížné zadání

  • Zadání považuji za středně náročné, tj. zvládnutelné pomocí vědomostí a zkušeností získaných během dosavadního studia na FIT VUT.
  • Za stěžejní považuji zejména požadavek zadání týkající se integrace eRPC a lwIP TCP stack zahrnující řešení spolehlivé a zabezpečené komunikace, požadavek na otestování výsledného řešení a požadavek detailní dokumentace a zveřejnění výsledného řešení na GitHub.
  • Požadavek bodu 7 na otestování lwIP implementace v prostředí Zephyr sice splněn nebyl (částečně odůvodněně pro Zephyr od verze 3 s vlastní transportní vrstvou, avšak již neodůvodněně pro nižší verze Zephyr umožňující využití lwIP), nicméně pro současnou verzi Zephyr byl splněn alternativním způsobem, který považuji za přijatelný.
Otázky k obhajobě:
  1. Stručně objasněte mechanismus, který jste použil pro nastavení hodnot uvedených v Tab. 5.1 (str. 33) a Tab. 5.2 (str. 43).
  2. Proč jste implementoval jen dynamickou a ne také statickou politiku přidělování prostředků v eRPC (konec části 5.3, str. 35)?
  3. Proč je v baremetal aplikacích založených na lwIP od NXP (viz konec prvního odstavce na str. 42) problém využít přerušení?
Výsledný počet bodů navržený oponentem: 75

Známka navržená oponentem: C

Odpovědnost: Mgr. et Mgr. Hana Odstrčilová