Systemy wbudowane i Internet of Things to jeden z tych kierunków, gdzie granica między teorią a praktyką jest szczególnie cienka. Recenzenci na ETI Politechniki Gdańskiej czy w Katedrze Elektroniki AGH oczekują działającego prototypu, wyników pomiarów i analizy kodu. Sama dokumentacja architektoniczna bez uruchomionego sprzętu nie wystarczy. Ten tekst pokazuje, jak zaplanować i napisać pracę magisterską z tego obszaru: od wyboru tematu, przez metodologię, po normy i typowe błędy, które kończą obronę pytaniem „a czy to w ogóle działa?”.
Wiele osób traktuje pracę z IoT jak projekt zaliczeniowy: podpiąć moduł, wysłać pakiet MQTT, wkleić zrzut ekranu z Grafany. To za mało na ocenę bardzo dobrą. Komisja ocenia świadomość ograniczeń sprzętowych (RAM, Flash, pobór mocy), znajomość stosu protokołów od warstwy fizycznej w górę, umiejętność przeprowadzenia i interpretacji pomiarów oraz zrozumienie regulacji, bo urządzenia IoT to produkty wchodzące na rynek europejski, a nie tylko labowe zabawki. Poniżej znajdziesz konkretne odpowiedzi na pytania, z którymi magistranci z tej dziedziny przychodzą najczęściej.
Specyfika kierunku
Zakres tematyczny
Systemy wbudowane to mikrokontrolery i mikroprocesory zoptymalizowane pod konkretne zadania: AVR (ATmega, ATtiny), ARM Cortex-M0/M3/M4/M7/M33. Warto rozumieć różnicę między architekturą Harvard (oddzielne magistrale danych i kodu, typowa dla AVR, wielu Cortex-M) a von Neumann (wspólna magistrala, prostsza, tańsza, ale wolniejsza w dostępie do instrukcji). W pracy magisterskiej należy wskazać, która architektura jest w projekcie i dlaczego to ma znaczenie dla czasu wykonania kodu.
System operacyjny czasu rzeczywistego (RTOS) to nie „Linux odchudzony”. FreeRTOS, Zephyr OS i RIOT OS to osobna kategoria: deterministyczny czas odpowiedzi, harmonogramowanie zadań (round-robin, priorytetowe, EDF), obsługa przerwań o gwarantowanym czasie ISR. FreeRTOS dominuje w projektach komercyjnych (ESP-IDF, STM32CubeMX go generują automatycznie). Zephyr jest preferowany przez Nordic Semiconductor i Google dla urządzeń Bluetooth LE. RIOT OS jest chętniej wybierany w projektach badawczych ze względu na przejrzystą architekturę modularną.
Protokoły IoT dzielą się na kilka warstw:
- aplikacyjne: MQTT (port 1883/8883, QoS 0/1/2, broker np. Mosquitto, EMQX, HiveMQ), CoAP (UDP, REST dla urządzeń z ograniczonymi zasobami), AMQP (enterprise, kolejki wiadomości, RabbitMQ)
- sieci LPWAN: LoRaWAN (nielicencjonowane pasmo 868 MHz EU, klasy A/B/C, The Things Network jako bezpłatna infrastruktura testowa, zasięg 2-15 km, payloady do 250 bajtów), NB-IoT (licencjonowane LTE, operatorzy PL: T-Mobile, Play, zasięg sieci komórkowej, latencja 1-10 s), Sigfox (zasięg nawet 50 km, 140 wiadomości/dzień, ograniczone zastosowanie)
- sieci krótkiego zasięgu: Bluetooth LE 5.x (BLE, 2.4 GHz, zasięg do 400 m w trybie Long Range, Coded PHY, profile GATT), Zigbee/Thread (mesh, 2.4 GHz, Thread używa IPv6 co upraszcza integrację z IP)
Edge computing i fog computing to tematy na dobry rozdział teoretyczny. Edge: przetwarzanie danych bezpośrednio na urządzeniu lub bramce (np. Raspberry Pi jako edge node). Fog: warstwa pośrednia między urządzeniami a chmurą. TinyML to wdrażanie modeli ML (sieci neuronowe, drzewa decyzji) bezpośrednio na mikrokontrolerze, bez przesyłania danych do chmury.
Platformy sprzętowe
Wybór platformy determinuje możliwości projektu:
- STM32 (STMicroelectronics): szeroka rodzina Cortex-M. STM32L4 do aplikacji bateryjnych (zasięg trybów uśpienia Stop/Standby, pobór prądu w trybie sleep ~10 µA). STM32G4 do sterowania silnikami (DAC, timerki zaawansowane, wsparcie dla FOC). STM32H7 do zastosowań wymagających dużej mocy obliczeniowej (FPU podwójnej precyzji, 480 MHz, Cortex-M7).
- ESP32-S3 (Espressif): WiFi 4 + BT 5, wbudowany AI accelerator (2x Xtensa LX7, 512 KB SRAM, 8 MB PSRAM w pakiecie). Tańszy i szybszy w prototypowaniu niż STM32.
- Nordic nRF5340 (Nordic Semiconductor): dual-core Cortex-M33, dedykowany do BLE 5.x + Thread/Zigbee. nRF52840 to poprzednik (monocore), szeroko stosowany w komercyjnych urządzeniach BLE
- Raspberry Pi 4/5: Linux (Raspberry Pi OS Bookworm), quad-core Cortex-A72 (Pi 4) lub Cortex-A76 (Pi 5), do 8 GB RAM. Nie to samo co mikrokontroler, brak gwarancji real-time bez RT kernel patch lub dodatkowego mikrokontrolera
- BeagleBone Black/AI-64: open hardware, wsparcie dla PRU (Programmable Real-time Units) – deterministyczna obsługa sygnałów GPIO bez systemu operacyjnego na liniach PRU
- FPGA: Xilinx (teraz AMD) seria Artix-7, Zynq-7000 (FPGA + ARM Cortex-A9). Intel (Altera) seria Cyclone V. Do implementacji szybkich protokołów komunikacyjnych, filtrów sygnałowych, co-procesowania z mikroprocesorem
Główne ośrodki akademickie w Polsce z silnym profilem w tej dziedzinie to Politechnika Gdańska (Wydział Elektroniki, Telekomunikacji i Informatyki), AGH w Krakowie (Katedra Elektroniki, Katedra Telekomunikacji), Politechnika Wrocławska (Katedra Systemów i Sieci Komputerowych) i Politechnika Warszawska (Instytut Elektroniki i Technik Informacyjnych).
Tematy prac magisterskich
Kilka realizowanych projektów, które pokazują, czego oczekują komisje egzaminacyjne.
Projekt i implementacja węzła IoT do monitorowania jakości powietrza
Sprzęt: STM32L4 (np. STM32L432KC lub Nucleo-L476RG), czujnik pyłu SDS011 (laser, komunikacja UART, PM2.5/PM10), czujnik środowiskowy BME680 (temperatura, wilgotność, ciśnienie, VOC, I2C). System: FreeRTOS, zadania dla akwizycji danych z czujników, zadanie publikacji po LoRaWAN (modem RAK3172 lub własna implementacja na SX1276). Aktywacja ABP (Activation By Personalization) lub OTAA w The Things Network. Dane trafiają przez TTN Webhooks do bazy InfluxDB, wizualizacja w Grafana. Praca opisuje schemat PCB, firmware w C (STM32CubeMX + HAL), format payloadu Cayenne LPP, retransmisje i politykę QoS w LoRaWAN.
Optymalizacja zużycia energii urządzenia BLE
Nordic nRF52840 (lub nRF5340). Analiza trybów systemu: EM0 (aktywny, ~5-6 mA), EM1 (CPU wyłączone, peryferia aktywne, ~1 mA), EM2 (głęboki sen, RTC aktywny, ~2-3 µA), EM3 (RAM retention, bez zegara, ~0.5 µA), EM4 (hibernate, ~25 nA). Cel: urządzenie BLE z transmisją co 10 minut powinno zużywać w trybie uśpienia poniżej 10 µA. Pomiary: Nordic Power Profiler Kit II (PPK2) – 0.3 µA do 1 A, rozdzielczość 0.1 µA, próbkowanie 100 kSps. Narzędzie Energy Profiler w nRF Connect for Desktop. Wyniki w postaci wykresów prądu vs czas, obliczenia żywotności baterii CR2032 (225 mAh) i AA (2500 mAh).
Bezpieczna aktualizacja firmware OTA dla ESP32
Implementacja mechanizmu OTA (Over-the-Air Update) dla ESP32 z weryfikacją podpisu cyfrowego ECDSA-P256. Schemat: serwer HTTP/S udostępnia nowe firmware podpisane kluczem prywatnym (openssl genpkey), ESP32 pobiera, weryfikuje podpis kluczem publicznym wgranym do flash, akceptuje lub odrzuca. ESP-IDF ma wbudowaną obsługę secure boot i flash encryption. Praca analizuje wektor ataku man-in-the-middle, downgrade attack (rollback prevention przez anti-rollback counter), failed update recovery (partycja OTA_0/OTA_1 + partycja fabryczna).
Sterowanie silnikiem BLDC algorytmem FOC
STM32G4 z biblioteką X-CUBE-MCSDK (Motor Control SDK). FOC (Field Oriented Control) to sterowanie wektorem strumienia magnetycznego – lepsza odpowiedź momentu, cichsze działanie niż trapezoidal commutation. Praca opisuje enkoder (AS5048A SPI lub hall sensors), pętlę prądu (PI regulator, ~20-40 kHz), pętlę prędkości (~1 kHz), implementację algorytmu Clarke/Park transforms w C na Cortex-M4 z FPU. Pomiary: oscyloskop Tektronix na prądzie fazowym, FFT harmonicznych.
TinyML na mikrokontrolerze
TensorFlow Lite Micro (TFLM) na Arduino Nano 33 BLE Sense (nRF52840, 256 KB RAM, 1 MB Flash). Cel: wykrywanie słów kluczowych (keyword spotting) z modelem sieci neuronowej. Pipeline: nagrania dźwięków (własny dataset lub Speech Commands Dataset Google), konwersja do MFCC (Mel-frequency cepstral coefficients), trening modelu w Python (Keras/TF), konwersja do .tflite + quantization (int8), konwersja do C array, kompilacja i wdrożenie. Metryki: accuracy na zestawie testowym, latencja inferencji (ms), zużycie RAM (statyczne dane modelu vs runtime arena).
Sterownik PLC na Raspberry Pi 4
OpenPLC Runtime v3 na Raspberry Pi 4 (Raspberry Pi OS). Programowanie w IEC 61131-3: Ladder Diagram lub Structured Text. Komunikacja: Modbus RTU po RS-485 (adapter USB-RS485) do podrzędnych urządzeń (czujniki, przekaźniki), Modbus TCP przez Ethernet do systemu SCADA (np. ScadaBR, Node-RED). Praca analizuje determinizm czasu cyklu PLC na Linux (bez RT patch: jitter do kilku ms, z PREEMPT_RT: jitter poniżej 1 ms), porównanie z klasycznym sterownikiem PLC (Siemens S7-1200).
Metodologia
Projektowanie sprzętowe
Schemat elektryczny i layout PCB to elementy wymagane w projektach ze sprzętem własnym (nie w projektach na modułach deweloperskich). Narzędzia: KiCad 7 lub 8 (open source, do profesjonalnych projektów), Altium Designer (standard komercyjny, uczelnie mają licencje studenckie). Schemat musi zawierać: schemat zasilania (regulatory, filtry, zabezpieczenia), schematy interfejsów (UART, SPI, I2C, USB), schemat RF (LoRa/BLE): trace impedance 50 Ohm, via stitching pod anteną.
Symulacje przed prototypem: LTspice (Analog Devices, bezpłatny) do symulacji zasilania i filtrów, Proteus do symulacji mikrokontrolera z kodem (wymagana licencja). Symulacja nie zastąpi pomiarów, ale pozwala zweryfikować projekt zasilania bez uszkodzenia sprzętu.
Pomiary i sprzęt laboratoryjny
Pomiary to kręgosłup pracy eksperymentalnej:
- Oscyloskop cyfrowy: Rigol DS1054Z (4 kanały, 50 MHz, hackable do 100 MHz), Tektronix TDS2024C lub nowszy. Do analizy sygnałów SPI/I2C/UART wbudowane dekodery protokołów
- Analizator logiczny: Saleae Logic Pro 8/16 (USB, 500 MSps, dekodowanie ponad 100 protokołów). Alternatywa budzetowa: sigrok-compatible (Cypress FX2), oprogramowanie PulseView
- Multimetr precyzyjny: Fluke 87V lub podobny do pomiarów DC
- Analizator widma RF: TinySA Ultra (100 kHz-5.3 GHz, 109 dolarów) do weryfikacji emisji modułów radiowych, pomiarów harmonicznych
- Nordic Power Profiler Kit II: dedykowany do pomiarów mocy dla układów Nordic, ale działa też z innymi urządzeniami 3.3V (zakres 0.3 µA-1 A).
Środowisko programistyczne
Języki: C i C++ to standard dla systemów wbudowanych (HAL/LL libraries STM32, ESP-IDF w C, Arduino framework w C++). MicroPython i CircuitPython są używane do szybkiego prototypowania (nie do produkcji z ograniczeniami RAM). Rust embedded to trend akademicki: framework Embassy (async/await dla systemów embedded), crate cortex-m, Probe-rs jako debugger. Rust daje gwarancje bezpieczeństwa pamięci na poziomie kompilatora (brak null pointer dereferencing, brak data races).
Środowiska IDE: STM32CubeIDE (Eclipse-based, generowanie kodu HAL z CubeMX, debugger ST-LINK). PlatformIO jako plugin VS Code obsługuje ponad 1000 płytek, zarządzanie bibliotekami, CI/CD (GitHub Actions). Debugging: OpenOCD przez SWD (Serial Wire Debug, 2 linie zamiast JTAG 5-linii) lub JTAG, GDB, semihosting dla printf przez debugger.
Analiza protokołów sieciowych: Wireshark dla MQTT (przechwytywanie na interfejsie sieciowym brokera), MQTT Explorer (GUI, subskrypcje tematów, przeglądanie wiadomości). Dekodowanie protokołów szeregowych: logicaly (analizator online do plików Saleae), Logic 2 (oprogramowanie Saleae). Analizatory RS-232/I2C/SPI można też emulować przez Python (pyserial, smbus2) i własne skrypty.
Wyślij fragment tekstu, bezpłatną wycenę otrzymasz w 24 h. Poprawki bez limitu w cenie usługi.
Normy i regulacje
To sekcja, której brakuje w większości prac magisterskich z systemów wbudowanych. Komisja często pyta właśnie tutaj.
Normy EMC i certyfikacja
Każde urządzenie elektroniczne sprzedawane w UE musi przejść ocenę zgodności:
- EN 55032 (klasa A/B emisje elektromagnetyczne od urządzeń multimedialnych), EN 55035 (odporność na zakłócenia)
- EN 61000-3-2: ograniczenia harmonicznych prądu (dotyczy urządzeń powyżej 75 W, ale warto wspomnieć)
- Certyfikacja CE dla modułów RF: dyrektywa RED 2014/53/UE (Radio Equipment Directive), art. 3 wymagania: bezpieczeństwo elektryczne (art. 3.1a), kompatybilność elektromagnetyczna (art. 3.1b), efektywne użycie widma (art. 3.2). Moduły certyfikowane (ESP32, Nordic nRF52840 w module) mają gotową deklarację DoC – projekt magisterski korzystający z takich modułów korzysta z tej certyfikacji
- FCC Part 15 (USA) i IC (Industry Canada) – wymienić gdy projekt ma szansę na wdrożenie komercyjne
- Normy IPC-A-610 (jakość lutowania PCB, inspekcja wizualna i X-ray) – istotne gdy projekt obejmuje własną produkcję PCB
Normy cyberbezpieczeństwa
- IEC 62443: norma dla cyberbezpieczeństwa systemów przemysłowych (OT/ICS/IoT). Definiuje poziomy bezpieczeństwa SL1-SL4. W pracy magisterskiej z IoT przemysłowym warto przywołać SL2 jako cel
- ETSI EN 303 645 (od 2022): norma cyberbezpieczeństwa dla urządzeń IoT klasy konsumenckiej. 13 podstawowych wymagań, m.in.: brak domyślnych haseł, możliwość aktualizacji firmware, polityka ujawniania podatności, minimalizacja powierzchni ataku
- Cyber Resilience Act (CRA) UE 2024: rozporządzenie dla produktów cyfrowych z elementami cyfrowymi (w tym IoT). Producenci muszą zgłaszać aktywnie wykorzystywane podatności do ENISA w ciągu 24h. Wymogi obowiązują od 2027 (dla większości produktów).
- RODO (GDPR): urządzenia IoT zbierające dane użytkowników (lokalizacja, aktywność, dane zdrowotne) podlegają przepisom o ochronie danych. Art. 5 zasady: minimalizacja danych (zbieraj tylko to co potrzebne), ograniczenie celu, integralność i poufność. Dla pracy magisterskiej: opisz, jakie dane zbiera urządzenie, gdzie są przechowywane, przez jaki czas
Ramy prawne
- Rozporządzenie RED 2014/53/UE: obowiązuje dla każdego urządzenia radiowego. Producent (lub importer do UE) sporządza Deklarację Zgodności (DoC), przechowuje dokumentację techniczną 10 lat. W przypadku projektu akademickiego obowiązek formalny nie istnieje, ale opis zgodności z normami wzmacnia pracę
- Ustawa z 16.07.2004 Prawo telekomunikacyjne (Dz.U. 2004 nr 171 poz. 1800 ze zm.): reguluje użytkowanie częstotliwości radiowych w Polsce. Pasmo 868 MHz (LoRaWAN) jest dostępne na podstawie pozwolenia generalnego UKE (moc do 25 mW ERP, duty cycle do 1%). Pasmo 2.4 GHz (BLE, Zigbee, WiFi) analogicznie
- Dyrektywa GPSD 2023/988/UE (General Product Safety Directive, od 13.12.2024): zastępuje dyrektywę 2001/95/WE. Każdy produkt konsumencki wprowadzany do obrotu musi być bezpieczny. Dotyczy urządzeń IoT sprzedawanych przez internet
- UDT (Urząd Dozoru Technicznego): jeśli urządzenie IoT steruje lub monitoruje urządzenia ciśnieniowe (kotły, zbiorniki, instalacje przemysłowe), może podlegać nadzorowi UDT zgodnie z ustawą z 21.12.2000 o dozorze technicznym
- Dyrektywa WEEE 2012/19/UE (zużyty sprzęt elektryczny i elektroniczny) i RoHS 2011/65/UE (ograniczenie substancji niebezpiecznych: ołów, rtęć, kadm, chrom sześciowartościowy, PBDE, PBB): każde urządzenie elektroniczne wprowadzane na rynek UE musi spełniać RoHS. Dla projektów edukacyjnych bez komercjalizacji: wspomnij w pracy jako świadomość regulacyjna
Typowe błędy
Brak analizy poboru mocy
To najczęstszy problem w pracach o urządzeniach bateryjnych. „Działa przez 2 tygodnie” to nie wynik. Komisja oczekuje: pomiarów prądu w każdym trybie (aktywny, idle, uśpienie), obliczeń zużycia energii w typowym cyklu pracy, szacowanej żywotności baterii (mAh / średnie zużycie = godziny). Użyj Nordic PPK2 lub dedykowanego miernika mocy, nie multimetru (za wolne próbkowanie dla impulsów BLE).
Polling zamiast przerwań i RTOS
HAL_Delay(100) w pętli głównej blokuje cały procesor. W systemach real-time to błąd projektowy. Przerwania (IRQ) i mechanizmy RTOS (semafory, kolejki, timery programowe) pozwalają na reakcję w czasie mikrosekund bez marnowania cykli CPU na aktywne czekanie. Promotorzy ze znajomością systemów wbudowanych wyłapią tę pomyłkę natychmiast.
Brak obsługi błędów komunikacji
Urządzenie IoT działa przez miesiące bez nadzoru. Sieć LoRaWAN może być niedostępna przez kilka godzin. Broker MQTT może się zresetować. Praca musi opisywać: timeout przy próbie połączenia, mechanizm reconnect (exponential backoff: pierwsze ponowienie po 1 s, kolejne po 2 s, 4 s, 8 s… do limitu), buforowanie danych lokalnie gdy sieć niedostępna (FIFO w SRAM lub na karcie SD), watchdog hardware (IWDG w STM32) który zrestartuje urządzenie po zawieszeniu.
Pominięcie testów EMC
Prototyp na płytce stykowej lub domowej PCB może emitować zakłócenia, które w badaniu EMC nie przejdą klasy B. Jeśli projekt ma szansę na wdrożenie, opisz środki zaradcze: dobry ground plane na PCB, filtry ferrytowe na liniach zasilania, kondensatory bypass blisko VDD pinów mikrokontrolera (100 nF ceramiczny + 10 µF elektrolityczny), prawidłowy routing sygnałów wysokoczęstotliwościowych. TinySA pozwala zmierzyć emisje promieniowane w laboratorium nawet bez komory bezechowej (wyniki orientacyjne, nie certyfikacyjne).
Mieszanie poziomów logicznych 3.3V i 5V
Wejścia cyfrowe mikrokontrolerów 3.3V (STM32, ESP32, nRF) mają absolutny maksymalny napięcie wejściowy 3.3V lub 3.6V. Podanie 5V bez level shiftera uszkadza wejście (lub cały układ) nieodwracalnie. Konwerter poziomów: BSS138 (N-MOSFET, dwukierunkowy, pasywny), TXS0108E (Texas Instruments, bidirectional, 8-kanałowy), prosty dzielnik napięcia dla sygnałów jednokierunkowych. Opisz poziomy logiczne każdego interfejsu w projekcie.
Brak mechanizmu watchdog
Urządzenie wbudowane zainstalowane w terenie nie ma komu nacisnąć resetowania. Watchdog hardware (IWDG: Independent Watchdog, WWDG: Window Watchdog w STM32) to licznik sprzętowy: jeśli firmware nie wykona HAL_IWDG_Refresh() w określonym czasie (np. 10 s), mikrokontroler resetuje się automatycznie. Konfiguracja IWDG powinna pojawić się w projekcie IoT obowiązkowo, nie opcjonalnie.
FAQ
Ile stron powinna mieć praca magisterska z systemów wbudowanych?
Na większości polskich uczelni technicznych norma wynosi 60-100 stron bez załączników. Przy projekcie sprzętowym załączniki są obszerne: schemat elektryczny, layout PCB (kilka warstw), pełny kod firmware (lub link do repozytorium). Promotorzy AGH i PG zazwyczaj akceptują 70-85 stron tekstu + załączniki. Sprawdź wymagania swojego wydziału, bo liczba stron nie jest ujednolicona.
Czy Arduino kwalifikuje się jako platforma do pracy magisterskiej?
Arduino Uno (ATmega328P, 16 MHz, 2 KB SRAM) to za słaby sprzęt dla zaawansowanej pracy magisterskiej. Arduino Nano 33 BLE Sense (nRF52840) lub Arduino Portenta H7 (STM32H747, dual-core) są akceptowalne jako platforma, szczególnie dla TinyML i prototypowania. Jeśli używasz Arduino IDE, rozważ przejście na PlatformIO z tym samym sprzętem. Promotorzy cenią wiedzę o tym, co jest „pod maską” bibliotek Arduino, nie samo klikanie w Blink.
Czy muszę mieć własne PCB, czy moduł deweloperski wystarczy?
Moduł deweloperski (Nucleo, Discovery, ESP32 DevKit, Raspberry Pi) wystarczy do pracy badawczej i algorytmicznej. Własne PCB jest wymagane lub bardzo dobrze oceniane gdy celem jest prototyp gotowy do wdrożenia (miniaturyzacja, specyficzne wymagania interfejsów, design docelowy). KiCad 8 jest bezpłatny i JLCPCB przyjmuje pliki Gerber od 2 dolarów za 5 sztuk PCB 10×10 cm. Dla pracy magisterskiej własna PCB wyraźnie podnosi ocenę.
Jak wybrać między FreeRTOS a Zephyr OS?
FreeRTOS: świetna dokumentacja, ogromna baza przykładów, generowany automatycznie przez STM32CubeMX, niski próg wejścia. Zephyr: pełny system (sterowniki, stosy sieciowe, BLE, Thread wbudowane), preferowany dla nRF5340 (nRF Connect SDK bazuje na Zephyr), steepsza krzywa uczenia. Jeśli projekt jest na STM32 bez BLE, wybierz FreeRTOS. Jeśli na Nordic z BLE lub Thread, wybierz Zephyr. Dla projektu na ESP32 z WiFi i MQTT: ESP-IDF + FreeRTOS (wbudowane).
Jak podejść do tematu bezpieczeństwa w pracy o IoT?
Wyróżnij trzy warstwy: bezpieczeństwo urządzenia (secure boot, flash encryption, brak domyślnych haseł, ETSI EN 303 645), bezpieczeństwo komunikacji (TLS 1.3 dla MQTT over TLS, certyfikaty X.509, DTLS dla CoAP) i bezpieczeństwo backendu (autoryzacja do API, izolacja sieci). Nie musisz implementować wszystkiego. Analiza zagrożeń metodą STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) dla Twojego systemu to solidna podstawa rozdziału o bezpieczeństwie i pokazuje świadomość problemu, nawet gdy implementujesz tylko część środków.
Jak powinno wyglądać repozytorium kodu dołączone do pracy?
Git (GitHub lub GitLab) to standard. Repozytorium powinno zawierać: katalog firmware/ z kodem C/C++ lub Rust, hardware/ ze schematami KiCad (pliki źródłowe, nie tylko PDF), docs/ z diagramami sekwencji i architekturą systemu, scripts/ z kodem po stronie serwera (Python, Node.js). README opisuje: jak skompilować i wgrać firmware (platformio run –target upload lub idf.py flash), jak uruchomić backend, jakie zależności są wymagane. Praca magisterska cytuje commit hash lub tag jako punkt odniesienia. Jeśli kod był pisany przez kilka miesięcy, historia commitów świadczy o procesie pracy i często robi wrażenie na promotorze bardziej niż sam wynik końcowy.
Kiedy warto użyć FPGA zamiast mikrokontrolera?
FPGA ma sens gdy potrzebujesz przetwarzania równoległego w czasie rzeczywistym: obsługa wielu strumieni danych jednocześnie, generowanie precyzyjnych sygnałów czasowych (PWM o rozdzielczości nanosekundowej), implementacja własnego protokołu komunikacyjnego na poziomie sprzętowym, akceleracja algorytmów (FFT, filtrów FIR/IIR). Mikrokontroler jest sekwencyjny, jeden rdzeń wykonuje jedną instrukcję na takt. Gdy algorytm wymaga przetwarzania np. 32 kanałów ADC w pipeline z latencją poniżej 1 µs, FPGA wygrywa. W pracy magisterskiej FPGA uzasadniaj konkretnymi wymaganiami wydajnościowymi, nie prestiżem. Używanie FPGA tam gdzie wystarczy STM32H7 to przerost formy nad treścią, który komisja zauważy.
