V rámci své práce se student zabýval návrhem a implementací informačního systému pro monitorování průběhu laboratorní výuky a podporu soutěží mezi studenty. Jádrem řešení je zařízení typu smartbutton připojené přes USB k laboratornímu PC, klientská aplikace běžící na pracovišti a centrální serverová webová aplikace s dashboardem pro vyučujícího.
Student v rámci práce realizoval firmware zařízení, klientský daemon pro komunikaci s pracovním počítačem a serverovou aplikaci umožňující sledování stavu jednotlivých pracovišť v reálném čase. Součástí řešení je také databázová vrstva, správa uživatelů a evidence měřicích sezení včetně historie výsledků.
Téma práce hodnotím jako spíše náročnější, a to především s ohledem na nutnost propojit několik odlišných částí systému do jednoho funkčního celku. Student musel zvládnout jak komunikaci s hardwarem, tak návrh a realizaci serverové části i uživatelského rozhraní.

Po formální stránce je práce na velmi dobré úrovni. Text je přehledně členěný, rozsah odpovídá požadavkům na bakalářskou práci a obrazové přílohy i diagramy vhodně doplňují výklad.

Přístup studenta k řešení projektu hodnotím jako zodpovědný a systematický. Student pracoval průběžně, reagoval na připomínky vedoucího a snažil se dotáhnout řešení do plně funkčního stavu, včetně praktického otestování systému a přípravy kompletního zdrojového kódu jako elektronické přílohy.

Zadání práce považuji za splněné v plném rozsahu. Výsledkem je funkční systém, který umožňuje vyučujícímu sledovat stav laboratorních pracovišť v reálném čase a zaznamenávat výsledky soutěžních kol.

Práci a přístup studenta hodnotím známkou A – 95 bodů. Points proposed by supervisor: 95

Předložená bakalářská práce se zabývá komplexním návrhem a realizací (tzv. end-to-end řešením) informačního systému pro monitorování pokroku studentů v laboratorní výuce a podporu soutěžních prvků. Systém efektivně integruje tzv. smart button s mikrokontrolérem ATtiny417 (byl k dispozici) s klientskou aplikací pro operační systém Windows a centrálním webovým serverem. Práce je psána v anglickém jazyce. Rozsahem, strukturou i technickou hloubkou (která zahrnuje tvorbu firmwaru v C, desktopového démona v .NET a webového portálu v ASP.NET Core) jde o nadprůměrnou bakalářskou práci.

Pozitivně hodnotím rozumné rozdělení odpovědností v architektuře: firmware řeší jednoduché nízkoúrovňové události, klientský démon klasifikuje komplexní gesta a server agreguje celkový stav. Tento návrh je inženýrsky správný, protože udržuje firmware mikrokontroléru jednoduchý a složitější logiku přesouvá do lépe modifikovatelného a udržovatelného softwaru na PC.

Za významnou kladnou stránku práce považuji důraz na provozní robustnost. Autor implementoval liveness mechanismy, periodické heartbeat zprávy, automatické znovupřipojení SignalR klienta, watchdog pro opětovné nalezení sériového portu a validaci API klíče vázaného na konkrétní pracovní stanici. Pozitivně hodnotím také lokální ochranu konfigurace démona, kdy je při změně přihlášeného Windows uživatele vymazán uložený API klíč. Tím se zásadně snižuje riziko zneužití klíče jiným studentem na téže stanici. Přiložená elektronická příloha je příkladná a skutečně obsahuje všechny tři hlavní funkční části systému.

Text práce je logicky členěný a srozumitelně popisuje použité technologie, hardwarové zapojení, firmware, architekturu systému, databázový návrh, klientského démona i serverovou část. Přehledné jsou zejména kapitoly věnované hardwaru, komunikačnímu protokolu a základní architektuře systému. Oceňuji také to, že autor sám v textu identifikuje některá omezení svého řešení, například použití metody EnsureCreated() místo plnohodnotných databázových migrací.

Technické výhrady:
-----------------------------
- Nedostatečné zabezpečení SignalR hubu: Architektura SignalR v ASP.NET Core definuje SignalR Huby standardně jako veřejně dostupné jakémukoli klientovi, který zná URL endpoint, pokud není použit atribut [Authorize]. Metoda RegisterDaemon sice funguje jako jakási vstupní brána, kde se ověřuje apiKey proti databázi a provádí se mapování spojení (Context.ConnectionId) na konkrétní computerId v paměti serveru (např. v ConcurrentDictionary). Nicméně ostatní kritické metody hubu již toto ověření neprovádějí, což znamená, že potenciální útočník na lokální síti může tyto metody volat napřímo a podvrhovat stavy jiných stanic. Z hlediska základní autentizace démona a ochrany API klíče na stanici je práce nadstandardní, ale pro reálné produkční nasazení v motivovaném studentském prostředí FEKTu by bylo nutné zabezpečení na serveru výrazně zpřísnit. Mimochodem, z kódu se zdá, že API klíč je v databázi uložen v otevřené (plain-text) podobě, což je rovněž kryptografický nedostatek.
- Nedostatky v databázovém návrhu: V databázové části je sice návrh plně funkční, ale v textové zprávě mi jednoznačně chybí explicitnější ER diagram, popis indexů, unikátních omezení (constraints) a dlouhodobá migrační strategie.
- Stručnější teoretická část: Teoretický úvod je spíše technologickým přehledem než hlubší analýzou problému. V práci chybí systematičtější a formální specifikace funkčních, nefunkčních a bezpečnostních požadavků, stejně jako popis provozních scénářů a mezních stavů.
- Absence kapitoly o testování: V práci postrádám samostatnou kapitolu Testing and Evaluation. Autor sice ukazuje screenshoty a popisuje funkčnost, ale nedokládá ji systematicky. Očekával bych explicitně definované testovací scénáře (např. chování při odpojení USB, reconnect serveru, neplatný API klíč, souběh více démonů, obnova po restartu serveru či latence dashboardu).
- Chyba v popisu UART parity (kap. 1.1.1): Text tvrdí, že pro sudou paritu (even parity) je paritní bit vždy 0 a pro lichou (odd parity) 1. To je nesprávné tvrzení, hodnota paritního bitu závisí na počtu jedniček v přenášených datech.
- Časování bzučáku: Uvedený teoretický vzorec pro generování frekvence bzučáku neuvažuje limitace 16bitového registru CCMP při plné frekvenci hodin periferie. Při požadavku na nízké tóny by hodnota registru přetekla. V textu by bylo vhodné přesněji sladit vzorec s konkrétním režimem časovače a jeho implementací v kódu.
- Jazyková úroveň: Text je bez problému pochopitelný, pouze se místy mísí americká (US) a britská (UK) konvence pravopisu.

Závěr:
---------
Hodnocená, implementačně zaměřená bakalářská práce zcela naplňuje cíle zadání a vykazuje vlastnosti, které jsou běžně vyžadovány spíše u diplomových (magisterských) prací. Student vyřešil reálný inženýrský problém od nejnižší hardwarové vrstvy až po moderní cloudové webové rozhraní. Zjištěné nedostatky jsou s ohledem na velký rozsah práce akceptovatelnou daní poplatnou reálnému softwarovému vývoji v časovém stresu a zásadně neovlivňují celkové hodnocení.

Doporučené hodnocení: A (výborně) 90 bodů Topics for thesis defence:

1. 1. Jak přesně je na straně serveru zajištěno, že jednotlivé SignalR metody mohou volat pouze oprávnění klienti, tedy například démon konkrétní pracovní stanice nebo administrátorský dashboard? Jak byste tento bezpečnostní model upravil pro produkční nasazení?
2. 2. Vysvětlete princip sudé a liché parity a uveďte důvod, proč v detekčních či samoopravných kódech v digitální technice preferujeme sudou paritu před lichou.
3. 3. V textu práce uvádíte vzorec pro výpočet registru CCMP na základě požadované frekvence bzučáku. Jakým způsobem se váš firmware ve smart buttonu vyrovná se situací, kdy by z API přišel požadavek na vygenerování frekvence tak nízké, že by hodnota pro registr CCMP přesáhla jeho 16bitovou kapacitu? Je tato validace ošetřena již v klientském démonu, nebo by došlo k přetečení čítače na MCU?

Points proposed by reviewer: 90