Hlavním cílem předložené závěrečné práce bylo navržení modulů pro sběr a vyhodnocení provozních dat z řídicích systémů. Dále bylo v zadání definováno několik parciálních cílů.

Obecně autor navrhl a propojil software Aveva Edge s frézovacím obráběcím strojem MCV754 Quick, který je vybaven řídicím systémem Sinumerik 840D sl (ŘS). Toto propojení bylo realizováno prostřednictvím standardu OPC UA, kterým je tento ŘS vybaven. V systému Aveva Edge bylo následně nastaveno komunikační rozhraní a byla navržena vizualizace vybraných realtime a historizovaných dat.

Jako databázové úložiště byl navržen a zkonfigurován SQL server od firmy Microsoft, který byl využit pro historizaci textových procesních dat s nízkou dynamikou změn a způsob řízení čtení dat v adresáři DriveVsa v ŘS stroje.

V práci se však nachází několik nedostatků, které snižují její celkovou úroveň.

V práci se vyskytují problémy ve formátování, kvalitě zpracování, přehlednosti a rozsahu. Nachází se zde více překlepů, u některých odstavců např. 3.4.1. by bylo vhodné prezentovat v přehledné tabulce místo jejich zpracování v souvislém textu.

V některých odstavcích chybí odkazy, např. Odst. 3.4. “... k prohlédnutí v příloze ??.” , dále se vyskytuje přetékání některých řádků např. str. 27 apod. Dále je problematický rozsah práce, kdy je požadováno min. 40 stran vlastního textu (dle směrnice děkana 2/2026) a zatímco práce obsahuje pouze 31 stran.

Z hlediska odborného bych měl několik dalších připomínek.

V práci byl pro přenos dat použit standard OPC UA, což je možné, ale je škoda, že se autor nezabýval i jinými typy přenosu informací z ŘS. Další možností mohl být přenos prostřednictvím interní komunikace ŘS - protokol PROFINET a komunikaci S7. Jelikož Aveva Edge tuto komunikaci podporuje, určitě by bylo dobré tuto variantu např. variantně analyzovat, vzhledem k rychlosti čtení a zátěži ŘS.

Další připomínkou může být např. definice period přenosu jednotlivých dat. V práci se např. v odst. 3.5 uvádí minimální perioda čtení dat 100 ms (vycházející z OPC UA serveru), která je využívána pro čtení vysokofrekvenčních dat, a dále se zde objevují hodnoty 1 s pro čtení “pomalých dat”. Bohužel v práci není širší analýza, zda tyto hodnoty vyhovují plánovanému použití, které se objevuje v závěru, a to je prediktivní údržba pohonů.

Přes uvedené výhrady autor splnil body zadání, což dokumentují přílohy (jak obrázkové, tak přiložené zdrojové soubory AVEVA Edge).

Práci doporučuji k obhajobě.

Diplomová práce se zabývá propojením platformy AVEVA Edge (Wonderware) se systémem Siemens Sinumerik 840D sl prostřednictvím standardu OPC UA a následnou vizualizací provozních dat frézovacího centra MAS MCV 754 Quick. Níže je práce posouzena podle jednotlivých kvalitativních kritérií.

## 1. Rozsah a úplnost řešení

Práce čítá 37 stran textu včetně příloh (seznam příloh na str. 36, samotné obrázky na str. 37–40), přičemž kapitoly věnované vlastnímu řešení (kapitoly 5 a 6) zahrnují méně než 20 stran. Takový rozsah je pro diplomovou práci technického zaměření nedostatečný. Porovnáme-li zadání s obsahem práce, zjistíme, že bod „Navrhněte programové moduly propojení Systémové platformy s řídícím systémem stroje" byl fakticky nahrazen pouhým popisem konfigurace hotového komerčního nástroje AVEVA Edge. Celá kapitola 5 (Nastavení programu) se skládá ze sekvence snímků obrazovky a jejich slovního popisu — žádný vlastní kód, žádný algoritmus, žádný navržený modul ve smyslu softwarového artefaktu. Zadání přitom explicitně hovoří o „návrhu programových modulů"; předložená práce tento požadavek nesplňuje.

Zadání dále uvádí jako charakteristiku problematiky použití „komunikačního rozhraní OPC UA, MQTT apod." Student implementoval výhradně OPC UA a MQTT ani jiný alternativní protokol nikde nerealizoval ani nevyhodnotil ani neodůvodnil, proč tak neučinil. Jediná zmínka o MQTT se nachází v rámci obecného teoretického přehledu OPC UA Pub/Sub (str. 9), kde student uvádí: *„Broker-based (s prostředníkem) – Použití MQTT protokolu."* Toto konstatování nelze považovat za splnění bodu zadání. Chybí jakékoli porovnání OPC UA a MQTT z hlediska latence, datové propustnosti, vhodnosti pro daný scénář ani demonstrace funkčního napojení.

## 2. Vlastní technický přínos a originalita

Práce v zásadě dokumentuje postup klikání v GUI prostředí AVEVA Edge: vytvoření OPC UA spojení, definici pracovních listů, nastavení historizace a sestavení HMI obrazovek. Tento postup je sice funkční, avšak z hlediska inženýrského přínosu představuje aplikaci existujícího komerčního nástroje podle jeho vlastní dokumentace, nikoli návrh a vývoj. Za jediný prvek s náznakem vlastního řešení lze považovat mechanismus synchronního triggerování záznamu pomocí proměnné `msClock` (str. 23): *„V něm je cyklicky negována lokální diskrétní proměnná msClock, která s frekvencí 100 ms mění stav mezi logickou nulou a jedničkou."* Student však ani zde neanalyzuje, zda a jak tento mechanismus ovlivňuje přesnost časového razítka záznamu ve vztahu k `SourceTimestamp` z OPC UA — viz otázka k obhajobě. Dalším prezentovaným přínosem je vytvoření databázové tabulky `AlarmTextDB` v MS SQL Serveru a dotazovací skript pro výpis textu alarmu (str. 29–30). Jde o rutinní SQL SELECT dotaz; ani zde student nepředkládá žádnou vlastní technickou inovaci.

## 3. Verifikace a experimentální podložení tvrzení

Toto kritérium je nejzávažnějším nedostatkem práce. Závěr práce (str. 33) konstatuje: *„Provedené testy prokázaly, že navržený koncept sběru a vizualizace dat vykazuje stabilitu, přehlednost a rychlou odezvu na změny technologických veličin."* Toto tvrzení není podloženo jediným naměřeným údajem v celém textu práce. Student nikde neuvádí:

- naměřenou skutečnou periodu vzorkování ani její odchylku od nominálních 100 ms,
- jitter záznamu ani statistiku časových razítek,
- propustnost datového toku (počet přenesených hodnot za jednotku času, počet ztracených vzorků),
- zatížení OPC UA serveru stroje při 80–100 souběžně monitorovaných proměnných,
- dobu odezvy HMI na změnu procesní hodnoty.

Student na str. 15 cituje dokumentaci Siemens a uvádí: *„Siemens pro výpočet maximálního počtu monitorovaných proměnných používá vzorec … při nejnižší možné periodě čtení, Sampling rate = 100 ms, vychází limit počtu čtených hodnot na 100 pro jedno spojení."* A vzápětí na str. 21 přiznává: *„Momentálně je přes OPC UA čteno někde mezi 80 až 100 hodnotami proměnných současně."* Student tedy pracuje těsně u deklarovaného limitu výrobce, aniž by měřením ověřil, zda se tato blízkost limitu projevuje na kvalitě dat. Závěr o „stabilitě" je tak zcela nepodložený.

Stejně nepodloženě je prezentována historizace: student rozlišuje retenční politiky (90 dnů pro diagnostická data pohonů a vřetena, 30 dnů pro méně kritická data, str. 23–24) bez měření nebo odhadu objemu generovaných dat. Není uvedeno, kolik MB/GB dat denně vzniká, ani zda zvolená retenční politika odpovídá kapacitě úložiště.

## 4. Metodologická úplnost

Práce neobsahuje žádné srovnání alternativních architektur ani zdůvodnění volby konkrétního řešení. Proč byla zvolena platforma AVEVA Edge a nikoli například open-source alternativa (Node-RED, Grafana + InfluxDB, Siemens Industrial Edge)? Proč byl jako databázový backend zvolen MS SQL Server Express a nikoliv například TimescaleDB nebo ClickHouse vhodný pro časové řady? Tyto volby jsou prezentovány jako samozřejmé, bez analýzy. Student na str. 17 uvádí tři možnosti historizace v AVEVA Edge (lokální úložiště, Historian, databáze) a vybírá kombinaci lokálního úložiště a SQL Serveru, avšak tuto volbu nezdůvodňuje z hlediska výkonu, nákladů ani škálovatelnosti.

## 5. Technicko-ekonomické zhodnocení

Práce neobsahuje žádné technicko-ekonomické zhodnocení. Nejsou uvedeny pořizovací ani licenční náklady platformy AVEVA Edge, není odhadnut přínos v podobě zkrácení prostojů nebo zkvalitnění diagnostiky, chybí porovnání s náklady na alternativní řešení. Přitom kapitola 1 (Úvod) sama uvádí jako motivaci: *„Dlouhodobé sledování takto získaných časových řad a správná interpretace jejich korelací pak prokazatelně vedou k systematickému zvyšování celkové efektivity zařízení OEE … minimalizaci neplánovaných prostojů."* Student si tedy sám stanovil ekonomicky relevantní cíl, ale v závěru jej nijak nevyčíslil ani nepřiblížil.

## 6. Kvalita závěrů a diskuse

Závěr práce (kapitola 7, str. 33–34) je z velké části rekapitulací toho, co bylo uděláno, nikoli hodnocením toho, co bylo dosaženo. Pasáže jako *„Nastavení bylo úspěšně otestováno, přičemž byla ověřena kontinuita datových toků a stabilita spojení"* nebo *„vykazuje stabilitu, přehlednost a rychlou odezvu"* jsou čistě verbální konstatování bez opory v datech. Perspektiva dalšího vývoje je odbyta dvěma větami na konci závěru a omezuje se na rozšíření o MQTT a implementaci prediktivní údržby — tedy přesně to, co zadání požadovalo a co nebylo realizováno.

## 7. Formální stránka a citace

Práce trpí opakovanými terminologickými a pravopisnými chybami. Již v nadpisu kapitoly 3.2 figuruje *„Anylýza"* místo „Analýza". Dále se vyskytují chyby jako *„zůsoby"* (místo způsoby), *„Architekture"*, uživatel označený *„UPCUA"* místo OPCUA (str. 12: *„Pro účely sběru dat však byl vytvořen nový uživatel UPCUA"*), a v klíčových slovech je výraz *„OPC UA"* uveden dvakrát. Sazba neodpovídá standardům akademické práce (nesprávný font, tečky v číslování nadpisů).

Citace [5] (str. 35) odkazuje na *„MCV 1016 QUICK"* — jiný typ stroje, než je řešený MCV 754 Quick. Jedná se o věcnou chybu v citaci, která navíc snižuje důvěryhodnost přílohy s parametry stroje. Celkový počet 12 citací, z nichž většina je online dokumentace, je pro diplomovou práci nedostatečný; doporučená literatura ze zadání nebyla využita.

---

## Shrnutí

Práce prokazuje základní orientaci v prostředí OPC UA a platformě AVEVA Edge a výsledný systém vykazuje elementární funkčnost. Nicméně ve světle požadavků kladených na diplomovou práci inženýrského programu trpí zásadními nedostatky: nedostatečným rozsahem, absencí vlastního programového vývoje, úplnou absencí experimentálního ověření jakéhokoli tvrzení, nevyužitím podstatné části zadání (MQTT, srovnání architektur) a neexistencí technicko-ekonomického zhodnocení. Schopnost interpretovat dosažené výsledky a vyvozovat z nich závěry nelze prokázat, neboť žádné měřené výsledky práce neobsahuje. Práci doporučuji k obhajobě, avšak hodnotím ji celkově stupněm **E**. Topics for thesis defence:

1. 2. Na str. 15 uvádíte, že limit OPC UA serveru 840D sl je přibližně 100 monitorovaných položek při periodě 100 ms na jedno spojení, a na str. 21 přiznáváte, že čtete 80–100 proměnných na tomto spojení. Jak blízko jste tedy reálnému limitu, jak se tato blízkost projevuje na kvalitě dat a jak byste systém škáloval při připojení dalšího stroje? Jak se systém chová při překročení tohoto limitu?
2. 3. Zadání explicitně uvádí rozhraní MQTT. Proč nebylo realizováno? V jakém scénáři by bylo MQTT výhodnější než OPC UA Client-Server a jak byste je technicky napojil na AVEVA Edge?
3. 4. Mechanismus `msClock` (str. 23) zavádí vlastní časovač pro synchronní záznam. Nezpůsobuje tento přístup drift nebo jitter vůči `SourceTimestamp` z OPC UA? Jak byste ověřil, že zaznamenaný čas skutečně odpovídá okamžiku vzniku vzorku na straně stroje?
4. 5. Závěr práce hovoří o stabilitě a rychlé odezvě systému, ale žádná měření tato tvrzení nedokládají. Jakou metodikou byste tato tvrzení zpětně ověřil a jaké konkrétní metriky byste zvolil?
5. 1. Práce neobsahuje žádné kvantitativní ověření systému. Jak byste experimentálně doložil propustnost datových toků, skutečnou periodu a jitter záznamu, chybovost přenosu a zatížení OPC UA serveru? Jaké hodnoty byste u svého řešení očekával a jak byste je změřil?