Bachelor's Thesis

An environment for the visual design, monitoring, and management of distributed control systems and IoT networks

Final Thesis 2.2 MB

Author of thesis: Jakub Kapitulčín

Acad. year: 2025/2026

Supervisor: doc. Ing. Vladimír Janoušek, Ph.D.

Reviewer: Ing. Jaroslav Rozman, Ph.D.

Abstract:

Distributed IoT systems often consist of numerous different devices and communication protocols. In these systems, data flow and control logic are frequently split across multiple standalone programs and configuration files, which increases developers’ mental overhead and makes it easy to overlook bugs and timing-dependent failures. This thesis presents a development environment that unifies modeling, deployment, monitoring, testing, and debugging for distributed IoT systems within a single configurable platform.

The platform is divided into four main components: an Electron-based IDE for visual development and runtime inspection, an Elixir/Phoenix gateway that serves as the network entry point, an Elixir server for device management and trace storage, and a portable C++17 runtime library for executing automata on supported target platforms. Device behavior is modeled visually as an Extended Finite State Machine with custom Lua hooks for guards, actions, and selected hardware interactions. Automata are stored in YAML format on the server and compiled into IR, which the runtime engine loads for execution.

The implemented platform supports configurable fault injection, execution trace recording, time-travel debugging, and structural analysis of automata networks using a Petri net lift. The system was tested using unit, integration, end-to-end deployment, hardware smoke tests on embedded targets, and manual testing. The result is a customizable platform that keeps the design model, runtime execution, fault reproduction, and analysis layers connected via a single state-machine-based representation.

Keywords:

extended finite state machine, Petri net, IoT, distributed systems, embedded systems, fault injection, time-travel debugging, execution tracing, Lua

Date of defence

17.06.2026

Result of the defence

Defended (thesis was successfully defended)

znamkaAznamka

Grading

A

Process of defence

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 A.

Topics for thesis defence

  1. Proč jste vytvořil vlastní runtime a nestavěl přímo nad ROS2?
  2. Co přesně se ukládá do execution trace a proč to stačí pro replay?
  3. V čem je váš model skutečně inspirovaný DEVS a v čem se od něj zásadně liší?
  4. Která část systému byla implementačně nejtěžší a proč?
  5. Jakým způsobem pracujete s časovými značkami? Jak probíhá synchronizace?
  6. Jak zajišťujete perzistentní uložení dat?

Language of thesis

English

Faculty

Department

Study programme

Information Technology (BIT)

Composition of Committee

doc. Ing. František Zbořil, CSc. (předseda)
doc. Ing. Michal Španěl, Ph.D. (místopředseda)
Ing. Jan Pluskal, Ph.D. (člen)
Ing. Aleš Smrčka, Ph.D. (člen)
Ing. Josef Strnadel, Ph.D. (člen)

Hodnocení odráží především rozsah a funkcionalitu výsledného realizačního výstupu, který dokládá schopnost studenta samostatně navrhnout a realizovat velmi komplexní systém.

Evaluation criteria Verbal classification
Informace k zadání

Zadání je poměrně komplexní a student si ho definoval sám na základě inspirace, poskytnuté vedoucím. Zadání bylo splněno. Výsledkem je prototypové řešení, které může být východiskem pro navazující práce. 

Práce s literaturou

Student si vyhledal studijní materiály samostatně a vhodně je použil.

Aktivita během řešení, konzultace, komunikace

Student pracoval samostatně a svoje řešení průběžně konzultoval.

Aktivita při dokončování

Technické řešení bylo před odevzdáním demonstrováno, ale definitivní obsah technické zprávy jsem před odevzdáním neviděl. 

Publikační činnost, ocenění

-

Points proposed by supervisor: 95

Grade proposed by supervisor: A

Reviewer’s report
Ing. Jaroslav Rozman, Ph.D.

Text práce a její monumentálnost působí dojmem, že nejen samotný text je psaný pomocí LLM, ale že se LLM ve velké míře podílela nejenom na tvorbě kódu, ale i na vymýšlení architektury. Vzhledem ale k tomu, že se student v práci orientuje a je schopen popsat, jak která část funguje, je evidentní, že LLM modely použil jen jako pomocníka a ne jako hlavního autora práce. Proto práci hodnotím stupněm B.

Evaluation criteria Verbal classification Points
Náročnost zadání

Evaluation level: značně obtížné zadání

Práce řeší velice komplexní problematiku programování a řízení IoT zařízení, proto ji hodnotím jako značně obtížnou.

Prezentační úroveň technické zprávy

Prezentační úroveň zprávy je dobrá.

80
Formální úprava technické zprávy

Práce je na dobré úrovni, ale student asi pro generování obrázků použil některý z generátorů, ale zapomněl uvést požadavek na dostatečnou velikost textu, který je tak bohužel v obrázcích nečitelný. 

70
Realizační výstup

Výsledkem poněkud megalomanské práce je fungující prostředí pro vizuální návrh, monitorování a správu distribuovaných řídicích systémů a IoT sítí.

89
Využitelnost výsledků

Práce by se dala zajisté použít jako základ pro další práci na tomto tématu, protože vzhledem k její obsáhlosti je v ní potřeba dořešit ještě spoustu věcí.

Rozsah splnění požadavků zadání

Evaluation level: zadání splněno

Zadání práce bylo splněno.

Rozsah technické zprávy

Evaluation level: přesahuje obvyklé rozmezí

Rozsah práce, která je navíc v angličtině, značně překračuje rozsah pro bakalářské práce a nejspíš i pro diplomové práce. Vzhledem k tomu, že ale zpracovává velice náročné zadání, není to na škodu, i když je z textu práce znát silné použití LLM modelů.

Práce s literaturou

Práce s literaturou je dobrá.

80
Topics for thesis defence:
  1. Proč jste vytvořil vlastní runtime a nestavěl přímo nad ROS2?
  2. Co přesně se ukládá do execution trace a proč to stačí pro replay?
  3. V čem je váš model skutečně inspirovaný DEVS a v čem se od něj zásadně liší?
  4. Která část systému byla implementačně nejtěžší a proč?
Points proposed by reviewer: 88

Grade proposed by reviewer: B

Responsibility: Mgr. et Mgr. Hana Odstrčilová