ZRZAVÝ, M. Gateway pro připojení řídící jednotky ohřívače vody do cloudu prostřednictvím domácí WiFi [online]. Brno: Vysoké učení technické v Brně. Fakulta elektrotechniky a komunikačních technologií. 2014.
Úkolem pana Bc. Martina Zrzavého bylo navrhnout a realizovat WiFi gateway zprostředkovávající komunikaci mezi řídící jednotkou ohřívače vody a cloudem. Pro gateway měl vytvořit a odladit potřebné softwarové vybavení. Součástí zadání bylo i ověření komunikace gateway s cloudem. Zadání práce vycházelo z požadavků firmy Honeywell International s.r.o. Diplomová práce navazovala na předcházející semestrální práci. V květnovém termínu se panu Zrzavému nepodařilo diplomovou práci obhájit, protože odevzdaná práce neobsahovala prakticky žádnou hardwarovou ani softwarovou realizaci. Částečnou příčinou nedokončení práce v květnovém termínu mohlo být i pozdní dodání WiFi modulu výrobcem. Pro dopracování práce však již měl všechny potřebné hardwarové i softwarové komponenty k dispozici. Pan Zrzavý disponoval průměrnými znalostmi z oblasti mikroprocesorové techniky. Měl problémy s logickým členěním textu práce. Během letního semestru postup a výsledky práce s vedoucím téměř nekonzultoval. To se výrazně změnilo během dvou měsíců, kdy pan Zrzavý svou diplomovou práci dopracovával. Konzultace využíval pravidelně a jeho aktivita byla výrazně větší než během letního semestru. Dle mého názoru diplomant splnil všechny body zadání práce, ovšem v mnoha částech je popis i navrhovaná hardwarová a softwarová řešení dosti povrchní. Pan Zrzavý provedl rešerši dostupných WiFi modulů na trhu. Dokázal provést návrh jednoduchého mikroprocesorového systému pro gateway. Bohužel volba hodnot mnohých součástek není zdůvodněna výpočtem. Diplomant také neřešil stanovení tolerancí jednotlivých součástek. Softwarové řešení umožňuje nejzákladnější funkci a to přenesení dat do cloudu. Např. preciznější nastavení TCP/IP protokolu nebo úvahy o možnosti budoucího rozšíření na IPv6 protokol práce již neobsahuje. I při vědomí značné povrchnosti hardwarového i softwarového řešení vytvořeného panem Bc. Martinem Zrzavým si dovoluji konstatovat, že diplomant prokázal jisté inženýrské schopnosti, a vzhledem k výše uvedeným skutečnostem hodnotím práci známkou dostatečně (E/55 bodů).
Cílem práce bylo navrhnout, realizovat, zdokumentovat a otestovat wifi gateway pro nahrávání dat do cloudu. Autor z formálního hlediska splnil body zadání, nicméně k již přepracované a podstatně doplněné práci mám následující výhrady: 1) Citace zdrojů je nedůsledná, např. na straně 17 informace v tabulce 1 o dosahu jednotlivých technologií zřejmě nepochází z autorem provedených experimentů. Celá řada obrázku v práci pak zřejmě byla převzata, aniž by bylo jasně zřejmé odkud (např. obr. 15, 16, 17). 2) Popis protokolu Modbus v kapitole 5 je dostatečný, avšak tvrzení, že maximální délka Modbus rámce 26 bajtů umožní vyčíst 12 dvoubajtových registrů, je při znalosti protokolu Modbus či pohledu na obr. 6 vnitřně rozporné. 3) Popis komunikačního protokolu v kapitole 6 je natolik stručný, že podle tohoto popisu prakticky není možné provést jednoznačnou implementaci. Vysvětlení některých polí je zcela nedostatečné, například v Tab. 5 pole „Potvrzení“ – není jasné co je potvrzováno, ani jakou formou (hodnotou) se potvrzení provede. V případě zprávy Time Response, jejíž struktura není zdokumentována vůbec, se opět něco blíže neurčeného potvrzuje. Pokud není pro práci struktura protokolu klíčová, tak definice protokolu měla být v příloze práce. Pokud naopak implementace nebo rozbor komunikačního protokolu představuje klíčovou část práce, tak měl být tento proprietární protokol zdokumentován mnohem pečlivěji a přehledněji. 4) Dokumentační úroveň práce je nízká, což lze mj. dokumentovat na schématech na str. 38 a 39. Ve schématech se vyskytují rezistory, jejichž hodnota byla autorem stanovena nezdokumentovaným způsobem. Autor, aniž by uvedl důvod, požaduje na řadě míst použití rezistorů o hodnotě přesně 499 ohmů, což je hodnota nepocházející ze žádné ze standardních řad E3/E6/E12/E24. V práci autor nijak nedokumentuje proč volil tuto ne zcela obvyklou hodnotu z řady E96. U produktu, kde má být prioritou cena výsledného produktu, je zcela neopodstatněný výběr součástek z řady s 1% tolerancí nevhodný. 5) Hodnoty rezistorů v zapojení optočlenu CNY17F na obr. 18 nejsou nijak zdokumentovány výpočtem, při použití tvrdého 3,3V zdroje a běžných 15 ohmových rezistorů s tolerancní 20% hrozí, že optočlen bude provozován již za hranicí výrobcem určených parametrů (If=80 mA vs 60 mA). Ze zapojení je pak zřejmé, že vzhledem k nízkému požadovanému kolektorovému proudu (Ic=1mA) je použití takto vysokého proudu If zcela neopodstatněné. 6) V příloze 2 pak je kompletní schéma zařízení, kde u krystalu a příslušných kondenzátorů není uvedeno ani označení, ani hodnoty. Vzhledem k jednoduchosti zapojení nelze v magisterské práci takovýto ledabylý a nedokumentovaný návrh obvodového zapojení akceptovat. Oceňuji, že se autor pokusil zdokumentovat SW pomocí grafických metod, nicméně i k této části práce mám výhrady: 7) Stavový automat tak, jak je uveden na obr. 22, je zřejmě na jedno použití, neboť v něm chybí alespoň náznak přechodu ze stavů Query_Timeout a Query_Complete někam dále - zřejmě do Query_Start. 8) Forma popisu aplikace stavovým automatem je vhodně zvolena, nicméně místy jsou doprovodné slovní formulace mimořádně neobratné. Například použít při popisu deterministického stavového automatu slovní spojení „při neznámém stavu automatu“ je nevhodné, neboť deterministický stavový automat se nemůže nacházet v neznámém stavu a detekce chyby při komunikaci rozhodně neznamená, že se automat dostal do neznámého stavu. 9) V konfigurační obrazovce gatewaye by uživatelskému komfortu by výrazně napomohlo, kdyby byl uživatel informován v jakém tvaru má WEP nebo WPA klíč zadat. Navíc označovat zabezpečovací standard WPA zkratkou WPA1 (viz str. 50) je pro budoucí uživatele poměrně matoucí. 10) V práci není vůbec zdokumentováno jakým způsobem uživatel nastavuje IP adresu zařízení - je nastavená uživatelem a je statická, nebo se automaticky předpokládá využití DHCP serveru ve wifi sítí ? Z práce není jasné, zda tuto zcela standardní funkcionalitu zařízení vůbec podporuje, nebo zda je uživatel trvale odsouzen k používání jediné IP adresy 192.168.1.1 s tím že veškerá komunikace zůstává v dané podsíti, neboť adresu gatewaye nelze staticky nastavit. Až z nahlédnutí do zdrojových kódu lze usoudit, že za provozu zařízení dostává přidělenu IP adresu dynamicky a statickou adresu nastavit nelze, nicméně v práci požadavek mít v AP aktivovaný DHCP server nikde zdokumentován není. 11) Některé zdrojové texty, které autor nepochybně modifikoval či vytvářel (např. VestaLogger.c, VestDriver.c) obsahují nulové množství komentářů. Skutečnost, že se v ostatních zdrojových textech míchají komentáře v anglickém a českém jazyce, zadavatel rovněž určitě neocení. Konstatuji, že předložená práce i po dopracování vykazuje celou řadu nedostatků a to jak v oblasti návrhu HW, tak v oblasti dokumentační. Z formálního hlediska byly sice jednotlivé body zadání splněny, avšak kvalita vytvořeného díla je nízká a neodpovídá magisterské práci.
eVSKP id 77458